upgrade-insecure-requests: actualiza las solicitudes inseguras antes de que salgan

upgrade-insecure-requests es una directiva de Content-Security-Policy que reescribe una URL http:// como https:// antes de que el navegador haga la solicitud. Con un solo encabezado de respuesta, todos los subrecursos http:// de la página se piden por https://. No es una reparación: si la URL segura no responde, la solicitud falla y no hay reintento por HTTP. Tampoco reemplaza a HSTS, porque los enlaces que salen hacia otro dominio no se tocan.

Qué hace upgrade-insecure-requests

La directiva trabaja antes del bloqueo de contenido mixto. Según la especificación del W3C, el mecanismo sube las solicitudes de recursos «a priori» inseguras a transporte seguro «before fetching them», y la reescritura ocurre antes de las verificaciones de contenido mixto y de CSP. Por eso la solicitud actualizada no se reporta como contenido mixto (Upgrade Insecure Requests, Candidate Recommendation del 8 de octubre de 2015, consultado el 2026-11-03). MDN describe lo mismo y marca la función como Baseline ampliamente disponible desde abril de 2018 (MDN, consultado el 2026-11-03).

Ahí está toda la ventaja: la solicitud insegura nunca sale, así que el bloqueo de contenido mixto no tiene nada que interceptar.

La cuarta fila es la que más se pasa por alto. Una navegación dentro del mismo sitio se actualiza; una navegación hacia otro dominio no (misma especificación, sección 1.2.2, consultada el 2026-11-03). Por eso HSTS sigue siendo una decisión aparte.

Cómo agregar upgrade-insecure-requests

Un encabezado de respuesta alcanza. Ponlo en cada respuesta HTML que pueda traer una URL insegura.

Content-Security-Policy: upgrade-insecure-requests

Si el hosting no permite tocar encabezados, queda la etiqueta meta. Solo cubre el documento que la incluye.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

No pongas block-all-mixed-content al mismo tiempo. MDN marca esa directiva como obsoleta, y la especificación del W3C indica que upgrade-insecure-requests se evalúa primero: con las dos presentes, block-all-mixed-content no hace nada (MDN, consultado el 2026-11-03). Usa una u otra.

Encuentra las URL inseguras antes de activar

Primero cuenta lo que tienes. Los dos comandos de abajo tardan un minuto y dejan una lista que puedes revisar. No encuentran todo: las URL que arma JavaScript y las que viven dentro del CSS no aparecen en el segundo comando.

# 1. ¿La página ya manda la directiva?
curl -sI https://example.com | grep -i '^content-security-policy'

# 2. ¿Qué recursos siguen en http://?
curl -s https://example.com \
  | grep -oE '(src|href)="http://[^"]+' \
  | sort -u

Corre el segundo comando en las plantillas que generan más páginas, no solo en la portada. Un checkout, un artículo y una landing suelen cargar terceros distintos. Si después siguen apareciendo avisos de contenido mixto, el diagnóstico está en cómo corregir el contenido mixto (en inglés).

Un despliegue en modo reporte te da la lista real. El navegador manda reportes de violación sin reescribir nada, así que puedes comparar lo que ve con lo que encontró tu revisión del código fuente.

Content-Security-Policy-Report-Only: upgrade-insecure-requests; report-uri /csp-reports

report-uri es el mecanismo anterior. report-to es la configuración más nueva, pero no son intercambiables en todos los hostings. No probamos la entrega de reportes en cada CDN, así que confirma que tu endpoint recibe algo antes de tomar un reporte vacío como prueba de que no hay problema.

Hasta dónde llega la directiva

Tres límites importan más que la sintaxis.

1. Navegaciones hacia terceros. Un enlace a otro dominio en http:// no se actualiza. La persona sale de tu página por HTTP y esta directiva no puede evitarlo.
2. Falta de HTTPS. No hay respaldo. Si la URL actualizada no responde por HTTPS, la solicitud falla y la página pierde ese recurso.
3. HSTS. La directiva no reemplaza Strict-Transport-Security. HSTS protege visitas futuras y la primera navegación; esta directiva protege las solicitudes de la página actual.

La especificación también trata las conexiones WebSocket aparte: una conexión ws:// insegura se actualiza a wss:// cuando aplica la directiva (sección 5, consultada el 2026-11-03). No probamos un endpoint WebSocket real, así que lo dejamos como comportamiento documentado, no como resultado medido.

Queda una duda de rastreadores. No probamos si Googlebot o un rastreador de IA respeta esta directiva. Un rastreador que renderiza como un navegador actual debería recibir la reescritura, pero no tenemos medición para ninguno y no vamos a presentar una suposición como resultado.

Un orden de migración que no rompe la página

Este es el orden que usaría en un sitio con años de URL http:// escritas a mano.

1. Inventaria las plantillas. Corre los dos comandos en las páginas que importan, no solo en la portada, y guarda la salida en un archivo.
2. Arregla lo que controlas. Pasa primero las imágenes, fuentes y scripts del mismo sitio a HTTPS. Esos fallos se ven y se corrigen en un despliegue.
3. Revisa cada tercero. Pide una URL HTTPS. Si un proveedor no la tiene, cambia o quita el recurso antes de activar la directiva.
4. Modo reporte durante un ciclo de rastreo. Compara los reportes con el inventario. Una URL que aparece en los reportes y no en el inventario es una que tu revisión del código se saltó.
5. Activa y verifica. Cambia al encabezado de aplicación, recarga con el panel de red abierto y confirma que ninguna solicitud sigue en http://. Deja HSTS como decisión separada.

El entregable es el inventario y su comparación con los reportes, no la línea del encabezado. El encabezado se pone en diez segundos. El inventario es el trabajo.

Tres formas de equivocarse

Las tres fallan en silencio en la primera carga, y dos parecen un problema del CDN.

1. Activar antes de que el proveedor tenga HTTPS. La solicitud se reescribe, el servidor del proveedor no responde en el puerto 443 y el recurso desaparece. No hay reintento HTTP.
2. Creer que cubre los enlaces de primer nivel. Un enlace a un socio en http:// sigue mandando a la persona por HTTP. Para eso está HSTS.
3. Poner las dos directivas CSP. block-all-mixed-content está obsoleta y no hace nada cuando la directiva de actualización está presente. Dos líneas parecen más seguras; una es la configuración correcta.

Cuándo no usarla

Si la página todavía depende de un script de terceros que solo existe en HTTP, activar la directiva lo rompe en la primera carga. Si lo que buscas es proteger la primera visita contra un ataque de degradación, la herramienta es HSTS, con sus propias decisiones de max-age y preload. Si solo tienes unas pocas URL inseguras, edítalas directamente: esta directiva es para la cola larga que no puedes arreglar esta semana.

No podemos decir cuánto tráfico cuesta un fallo de actualización. Depende de qué recurso falla y de qué hace la página sin él. Mide la página, no el encabezado.

Preguntas frecuentes

¿Es lo mismo que HSTS?

No. HSTS le dice al navegador que use HTTPS en solicitudes futuras a un host. upgrade-insecure-requests reescribe las solicitudes inseguras de la página actual. La especificación del W3C separa las dos y dice que esta directiva no reemplaza a HSTS (consultada el 2026-11-03).

¿Quita los avisos de contenido mixto?

La mayoría de las solicitudes de contenido mixto se reescriben antes de salir, así que ya no se hacen en claro. No arregla un recurso que no existe en HTTPS: esa solicitud falla.

¿Funciona en una etiqueta meta?

Sí, en el documento que la lleva. Un encabezado de respuesta cubre todas las respuestas HTML que configures; una etiqueta meta solo cubre su página.

¿Qué es el encabezado de solicitud Upgrade-Insecure-Requests?

Es otro encabezado. El navegador manda Upgrade-Insecure-Requests: 1 para avisar que sabe actualizar. Un servidor puede usarlo para devolver una redirección 307. Es detección de capacidad, no la directiva de aplicación.

¿Se puede usar con un CDN?

Sí, si el CDN transmite el encabezado de respuesta. Revisa una respuesta con curl -sI después del despliegue. No probamos el manejo de encabezados de cada CDN, así que verifica tu propio edge.

¿Googlebot la respeta?

No probamos Googlebot ni ningún rastreador de IA. Confírmalo con tus registros o con un fetch renderizado antes de depender de ello.

Siguiente paso

Cuando la página solo cargue por HTTPS, la siguiente pregunta es si el rastreador recibe el mismo HTML que ves tú. Revisa qué recibe realmente un rastreador de IA y usa la vista de página de QueryWin para comparar la solicitud con el resultado renderizado.