Schemeful SameSite

La definición de "mismo sitio" evoluciona para incluir el esquema de URL, por lo que los vínculos entre las versiones HTTP y HTTPS de un sitio ahora se registran como solicitudes entre sitios. Actualiza a HTTPS de forma predeterminada para evitar problemas siempre que sea posible o sigue leyendo para obtener detalles sobre los valores del atributo SameSite que se necesitan.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Mismo sitio con esquema modifica la definición de un sitio (web) del solo dominio registrable al esquema + dominio registrable. Puedes encontrar más detalles y ejemplos en Información sobre "mismo sitio" y "mismo origen".

La buena noticia es que, si tu sitio web ya se actualizó por completo a HTTPS, no tienes que preocuparte por nada. No cambiará nada para ti.

Si aún no actualizaste completamente tu sitio web, esta debe ser la prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio alternan entre HTTP y HTTPS, más adelante en este artículo, se describen algunas de esas situaciones comunes y el comportamiento asociado de la cookie SameSite.

Puedes habilitar estos cambios para realizar pruebas en Chrome y Firefox.

  • En Chrome 86, habilita about://flags/#schemeful-same-site. Haz un seguimiento del progreso en la página Estado de Chrome.
  • A partir de Firefox 79, configura network.cookie.sameSite.schemeful en true a través de about:config. Haz un seguimiento del progreso con el problema de Bugzilla.

Uno de los principales motivos del cambio a SameSite=Lax como valor predeterminado para las cookies fue proteger contra la falsificación de solicitudes entre sitios (CSRF). Sin embargo, el tráfico HTTP no seguro sigue siendo una oportunidad para que los atacantes de red manipulen las cookies que se usarán en la versión segura de HTTPS del sitio. Crear este límite adicional entre sitios entre los esquemas proporciona una defensa adicional contra estos ataques.

Situaciones comunes de esquemas cruzados

Anteriormente, navegar entre versiones de esquema cruzado de un sitio web (por ejemplo, vincular de http://sitio.ejemplo a https://sitio.ejemplo) permitía que se enviaran cookies SameSite=Strict. Ahora, se considera una navegación entre sitios, lo que significa que se bloquearán las cookies de SameSite=Strict.

Una navegación entre esquemas que se activa cuando se sigue un vínculo en la versión HTTP no segura de un sitio a la versión HTTPS segura. Se bloquearon las cookies SameSite=Strict y se permiten las cookies SameSite=Lax y SameSite=None; Secure.
Navegación entre esquemas de HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ✓ Se permite ✓ Se permite
SameSite=None;Secure ✓ Se permite ⛔ Bloqueado

Cómo cargar subrecursos

Cualquier cambio que realices aquí solo debe considerarse una solución temporal mientras trabajas para actualizar a HTTPS completo.

Algunos ejemplos de subrecursos incluyen imágenes, iframes y solicitudes de red realizadas con XHR o Fetch.

Anteriormente, cargar un subrecurso de esquema cruzado en una página permitía enviar o establecer cookies SameSite=Strict o SameSite=Lax. Ahora se trata de la misma manera que cualquier otro subrecurso de terceros o entre sitios, lo que significa que se bloquearán las cookies SameSite=Strict o SameSite=Lax.

Además, incluso si el navegador permite que se carguen recursos de esquemas no seguros en una página segura, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o de seguimiento entre sitios requieren Secure.

Un subrecurso de esquema cruzado que resulta de un recurso de la versión segura HTTPS del sitio que se incluye en la versión no segura HTTP. Se bloquearon las cookies SameSite=Strict y SameSite=Lax, y se permiten las cookies SameSite=None; Secure.
Una página HTTP que incluye un subrecurso de esquema cruzado a través de HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Se permite ⛔ Bloqueado

Cómo enviar un formulario con POST

Anteriormente, la publicación entre versiones de esquemas cruzados de un sitio web permitía que se enviaran cookies configuradas con SameSite=Lax o SameSite=Strict. Ahora, esto se considera una solicitud POST entre sitios; solo se pueden enviar cookies SameSite=None. Es posible que te encuentres con esta situación en sitios que presentan la versión no segura de forma predeterminada, pero que actualizan a los usuarios a la versión segura cuando se envía el formulario de acceso o de confirmación de la compra.

Al igual que con los subrecursos, si la solicitud es de un contexto seguro (por ejemplo, HTTPS) a un contexto no seguro (por ejemplo, HTTP), se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o de varios sitios requieren Secure.

Un envío de formulario de esquema cruzado que resulta de un formulario en la versión no segura de HTTP del sitio que se envía a la versión segura de HTTPS. Se bloquearon las cookies SameSite=Strict y SameSite=Lax, y se permiten las cookies SameSite=None; Secure.
Envío de formularios de esquema cruzado de HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Se permite ⛔ Bloqueado

¿Cómo puedo probar mi sitio?

Las herramientas y los mensajes para desarrolladores están disponibles en Chrome y Firefox.

A partir de Chrome 86, la pestaña Issue en DevTools incluirá problemas de Schemeful Same-Site. Es posible que veas los siguientes problemas destacados para tu sitio.

Problemas de navegación:

  • "Migrate entirely to HTTPS to continue having cookies sent on same-site requests": Es una advertencia que indica que la cookie se bloqueará en una versión futura de Chrome.
  • "Migrate entirely to HTTPS to have cookies sent on same-site requests": Es una advertencia que indica que la cookie se bloqueó.

Problemas de carga de subrecursos:

  • "Migrate entirely to HTTPS to continue having cookies sent to same-site subresources" o "Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources": Son advertencias que indican que la cookie se bloqueará en una versión futura de Chrome.
  • "Migrate entirely to HTTPS to have cookies sent to same-site subresources" o "Migrate entirely to HTTPS to allow cookies to be set by same-site subresources": Son advertencias que indican que la cookie se bloqueó. La última advertencia también puede aparecer cuando se envía un formulario POST.

Obtén más detalles en Sugerencias de prueba y depuración para Schemeful Same-Site.

A partir de Firefox 79, con network.cookie.sameSite.schemeful configurado en true a través de about:config, la consola mostrará un mensaje sobre los problemas de Schemeful Same-Site. Es posible que veas lo siguiente en tu sitio:

  • "La cookie cookie_name pronto se tratará como una cookie de varios sitios en http://site.example/ porque el esquema no coincide".
  • "La cookie cookie_name se trató como de varios sitios en comparación con http://site.example/ porque el esquema no coincide".

Preguntas frecuentes

Mi sitio ya está disponible por completo en HTTPS. ¿Por qué veo problemas en DevTools de mi navegador?

Es posible que algunos de tus vínculos y subrecursos aún apunten a URLs no seguras.

Una forma de solucionar este problema es usar HTTP Strict-Transport-Security (HSTS) y la directiva includeSubDomain. Con HSTS y includeSubDomain, incluso si una de tus páginas incluye accidentalmente un vínculo no seguro, el navegador usará automáticamente la versión segura.

¿Qué sucede si no puedo actualizar a HTTPS?

Si bien te recomendamos que actualices tu sitio por completo a HTTPS para proteger a los usuarios, si no puedes hacerlo por tu cuenta, te sugerimos que hables con tu proveedor de hosting para ver si puede ofrecerte esa opción. Si te alojas por tu cuenta, Let's Encrypt proporciona varias herramientas para instalar y configurar un certificado. También puedes investigar la posibilidad de mover tu sitio detrás de una CDN o de otro proxy que pueda proporcionar la conexión HTTPS.

Si aún no es posible, intenta relajar la protección de SameSite en las cookies afectadas.

  • En los casos en que solo se bloqueen las cookies de SameSite=Strict, puedes disminuir la protección a Lax.
  • En los casos en que se bloqueen las cookies Strict y Lax, y tus cookies se envíen a (o se configuren desde) una URL segura, puedes reducir las protecciones a None.
    • Esta solución fallará si la URL a la que envías las cookies (o desde la que las configuras) no es segura. Esto se debe a que SameSite=None requiere el atributo Secure en las cookies, lo que significa que es posible que esas cookies no se envíen ni se establezcan a través de una conexión no segura. En este caso, no podrás acceder a esa cookie hasta que tu sitio se actualice a HTTPS.
    • Recuerda que esto es solo temporal, ya que, con el tiempo, las cookies de terceros se eliminarán por completo.

¿Cómo afecta esto a mis cookies si no especificé un atributo SameSite?

Las cookies que no tienen un atributo SameSite se tratan como si hubieran especificado SameSite=Lax, y el mismo comportamiento entre esquemas también se aplica a estas cookies. Ten en cuenta que aún se aplica la excepción temporal a los métodos no seguros. Para obtener más información, consulta la mitigación de Lax + POST en las SameSiteFAQ de Chromium.

¿Cómo se ven afectados los WebSockets?

Las conexiones de WebSocket se seguirán considerando del mismo sitio si tienen el mismo nivel de seguridad que la página.

Same-site:

  • Conexión de wss:// desde https://
  • Conexión de ws:// desde http://

Entre sitios:

  • Conexión de wss:// desde http://
  • Conexión de ws:// desde https://

Foto de Julissa Capdevilla en Unsplash