google-chrome - unrecognized - <meta http-equiv="content-security-policy" content="upgrade-insecure-requests">

¿Qué es el encabezado HTTP "Solicitudes de actualización insegura"?

Question

Hice una solicitud POST a un sitio HTTP (no HTTPS), inspeccioné la solicitud en las Herramientas para desarrolladores de Chrome y descubrí que agregaba su propio encabezado antes de enviarlo al servidor:

Upgrade-Insecure-Requests: 1

Después de hacer una búsqueda en Upgrade-Insecure-Requests , solo puedo encontrar information sobre el servidor que envía this encabezado:

Content-Security-Policy: upgrade-insecure-requests

Esto parece relacionado, pero sigue siendo muy diferente, ya que en mi caso, el CLIENTE está enviando el encabezado en la Solicitud , mientras que toda la información que he encontrado se refiere al SERVIDOR que envía el encabezado relacionado en una Respuesta .

Entonces, ¿por qué Chrome (44.0.2403.130 m) agrega Upgrade-Insecure-Requests a mi solicitud y qué hace?

Actualización 2016-08-24:

Este encabezado se ha agregado desde entonces como una recomendación de candidato del W3C y ahora se reconoce oficialmente.

Para aquellos que acaban de encontrar esta pregunta y están confundidos, la excelente respuesta de Simon East lo explica bien.

El encabezado Upgrade-Insecure-Requests: 1 solía ser HTTPS: 1 en el borrador de trabajo anterior del W3C y Chrome le cambió el nombre en silencio antes de que el cambio fuera aceptado oficialmente.

(Esta pregunta se hizo durante esta transición cuando no había documentación oficial sobre este encabezado y Chrome fue el único navegador que envió este encabezado).

Answer 1

Esto explica todo:

La directiva de solicitud de actualización de inseguridad de la política de contenido HTTP (CSP) instruye a los agentes de usuario a tratar todas las URL inseguras de un sitio (aquellas servidas a través de HTTP) como si hubieran sido reemplazadas por URL seguras (aquellas servidas a través de HTTPS). Esta directiva está destinada a sitios web con un gran número de URL heredadas inseguras que deben reescribirse.

La directiva de actualización de solicitudes inseguras se evalúa antes que block-all-mixed-content y, si está configurada, esta última es efectivamente no operativa. Se recomienda establecer una directiva u otra, pero no ambas.

La directiva de actualización de solicitudes inseguras no garantizará que los usuarios que visiten su sitio a través de enlaces en sitios de terceros se actualicen a HTTPS para la navegación de nivel superior y, por lo tanto, no reemplacen el encabezado Strict-Transport-Security (HSTS), que aún debe establecerse con una edad máxima adecuada para garantizar que los usuarios no estén sujetos a ataques de eliminación de SSL.

Fuente: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

Answer 2

Respuesta corta: está estrechamente relacionada con el encabezado de respuesta Content-Security-Policy: upgrade-insecure-requests , lo que indica que el navegador lo admite (y de hecho lo prefiere).

Me tomó 30 minutos de Google, pero finalmente lo encontré enterrado en la especificación W3.

La confusión se produce porque el encabezado en la especificación era HTTPS: 1 , y así es como Chromium lo implementó, pero después de esto rompió muchos sitios web que estaban mal codificados (particularmente WordPress y WooCommerce) el equipo de Chromium se disculpó:

"Pido disculpas por la ruptura; aparentemente subestimé el impacto basado en los comentarios durante el desarrollo y la versión beta".
- Mike West, en Chrome Issue 501842

Su solución fue cambiarle el nombre a Upgrade-Insecure-Requests: 1 , y la especificación se ha actualizado para que coincida.

De todos modos, aquí está la explicación de la especificación W3 (como apareció en ese momento) ...

El campo de encabezado de solicitud HTTP HTTPS envía una señal al servidor que expresa la preferencia del cliente por una respuesta encriptada y autenticada, y que puede manejar con éxito la directiva de actualización de solicitudes inseguras para que esa preferencia sea lo más fluida posible.

...

Cuando un servidor encuentra esta preferencia en los encabezados de una solicitud HTTP, DEBE redirigir al usuario a una representación potencialmente segura del recurso que se solicita.

Cuando un servidor encuentra esta preferencia en los encabezados de una solicitud HTTPS, DEBE incluir un encabezado Strict-Transport-Security en la respuesta si el host de la solicitud es seguro para HSTS o condicionalmente seguro para HSTS [RFC6797].