upgrade-insecure-requests: actualiza cada solicitud insegura antes de que salga

upgrade-insecure-requests es una directiva de Content-Security-Policy que reescribe una URL http:// a https:// antes de que el navegador envíe la solicitud. Con una sola cabecera de respuesta, todos los subrecursos http:// de la página pasan a pedirse por https://. Es una reescritura, no una reparación: si la URL segura no responde, la solicitud falla y no hay vuelta atrás. Tampoco sustituye a HSTS, porque los enlaces a otro dominio se quedan como están.

Qué cambia upgrade-insecure-requests

Actúa antes que el bloqueo de contenido mixto. La especificación del W3C dice que el mecanismo actualiza las solicitudes de recursos «a priori» inseguras «before fetching them», y que la reescritura ocurre antes de las comprobaciones de contenido mixto y de CSP. Por eso una solicitud actualizada no se notifica como contenido mixto (Upgrade Insecure Requests, Candidate Recommendation del 8 de octubre de 2015, consultado el 2026-11-03). MDN describe el mismo comportamiento y marca la función como Baseline ampliamente disponible desde abril de 2018 (MDN, consultado el 2026-11-03).

Todo el valor está en ese momento: el navegador nunca llega a enviar la solicitud insegura, así que el bloqueo de contenido mixto no tiene nada que interceptar.

La cuarta fila es la que se olvida. Una navegación al mismo sitio se actualiza; una navegación a otro dominio no (misma especificación, sección 1.2.2, consultada el 2026-11-03). Por eso esta directiva no reemplaza a HSTS.

Cómo añadir la directiva

Basta una cabecera de respuesta. Colócala en todas las respuestas HTML que puedan contener una URL insegura.

Content-Security-Policy: upgrade-insecure-requests

Si el alojamiento no permite cambiar cabeceras, queda la etiqueta meta. Solo cubre el documento que la lleva.

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

No añadas block-all-mixed-content al lado. MDN marca esa directiva como obsoleta, y la especificación del W3C dice que upgrade-insecure-requests se evalúa primero, así que block-all-mixed-content no hace nada cuando están las dos (MDN, consultado el 2026-11-03). Elige una.

Encuentra las URL inseguras antes de aplicar

Empieza contando. Los dos comandos de abajo tardan un minuto y producen una lista que puedes revisar. No lo encuentran todo: las URL que construye JavaScript y las que están dentro del CSS no aparecen en el segundo comando.

# 1. ¿La página ya envía 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

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

Un despliegue en modo informe te da la lista real. El navegador envía informes de violación sin reescribir nada, así que puedes comparar lo que ve con lo que encontró tu análisis del código fuente.

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

report-uri es el mecanismo antiguo. report-to es la configuración más reciente, pero no son intercambiables en todos los alojamientos. No hemos probado la entrega de informes en cada CDN, así que confirma que tu endpoint recibe algo antes de tomar un informe vacío como prueba de que no hay problema.

Dónde se detiene la directiva

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

1. Navegaciones a terceros. Un enlace a otro dominio en http:// no se actualiza. El visitante sale de tu página por HTTP y esta directiva no puede impedirlo.
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 sustituye a 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 por separado: una conexión ws:// insegura se actualiza a wss:// cuando se aplica la directiva (sección 5, consultada el 2026-11-03). No hemos probado un endpoint WebSocket real, así que lo anotamos como comportamiento documentado, no como resultado medido.

Queda una pregunta de rastreadores sin respuesta. No hemos probado 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. Ejecuta 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, sustituye o elimina el recurso antes de aplicar la directiva.
4. Modo informe durante un ciclo de rastreo. Compara los informes con el inventario. Una URL que aparece en los informes y no en el inventario es una que tu análisis de código se saltó.
5. Aplica y verifica. Cambia a la cabecera de aplicación, recarga con el panel de red abierto y confirma que ninguna solicitud sigue en http://. Deja HSTS como decisión aparte.

El entregable es el inventario y su comparación con los informes, no la línea de la cabecera. La cabecera 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. Aplicar 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 al visitante 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 aún depende de un script de terceros que solo existe en HTTP, aplicar la directiva lo rompe en la primera carga. Si lo que quieres es proteger la primera visita frente a 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 la cabecera.

Preguntas frecuentes

¿Es lo mismo que HSTS?

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

¿Elimina 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. Una cabecera de respuesta cubre todas las respuestas HTML que configures; una etiqueta meta solo cubre su página.

¿Qué es la cabecera de solicitud Upgrade-Insecure-Requests?

Es otra cabecera. El navegador envía Upgrade-Insecure-Requests: 1 para indicar que sabe actualizar. Un servidor puede usarla 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 la cabecera de respuesta. Comprueba una respuesta con curl -sI después del despliegue. No hemos probado el manejo de cabeceras de cada CDN, así que verifica tu propio edge.

¿Googlebot la respeta?

No hemos probado 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 tú ves. Comprueba qué recibe de verdad un rastreador de IA y usa la vista de página de QueryWin para comparar la solicitud con el resultado renderizado.