Schemeful SameSite

La definición de "mismo sitio" está evolucionando para incluir el esquema de URL, de modo que los vínculos entre las versiones HTTP y HTTPS de un sitio ahora cuentan como solicitudes entre sitios. Actualiza a HTTPS de forma predeterminada para evitar problemas cuando sea posible o lee los detalles sobre los valores del atributo de SameSite necesarios.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Schemeful Same-Site modifica la definición de un sitio (web) a partir del dominio registrable del esquema y el dominio registrable. Puedes encontrar más detalles y ejemplos en Información sobre el "mismo sitio" y el "mismo-origen".

La buena noticia es que si tu sitio web ya está completamente actualizado a HTTPS, no tienes que preocuparte por nada. Nada cambiará para ti.

Si aún no has actualizado completamente tu sitio web, esta debe ser la prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio pasen de HTTP a HTTPS, a continuación se describen algunas de esas situaciones comunes y el comportamiento asociado de la cookie SameSite.

Puedes habilitar estos cambios para realizar pruebas tanto en Chrome como en Firefox.

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

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

Situaciones comunes entre esquemas

Navegar entre versiones entre esquemas de un sitio web (por ejemplo, vincular de http://site.example a https://site.example) antes permitiría que se enviaran cookies SameSite=Strict. Esto se considera una navegación entre sitios, lo que significa que se bloquearán las cookies SameSite=Strict.

Una navegación entre esquemas que se activa al seguir un vínculo en la versión HTTP no segura de un sitio a la versión HTTPS segura Se bloquearon las cookies estrictas de SameSite=, SameSite=Lax y SameSite=None; se permiten las cookies seguras.
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

Cargando subrecursos

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

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

Antes, la carga de un subrecurso de varios esquemas en una página permitiría que se enviaran o configuraran las cookies SameSite=Strict o SameSite=Lax. Se trata de la misma manera que con cualquier otro subrecurso de terceros o entre sitios, lo que significa que se bloqueará cualquier cookie SameSite=Strict o SameSite=Lax.

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

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

PUBLICAR un formulario

Antes, la publicación entre versiones entre esquemas de un sitio web permitía que se enviaran las cookies configuradas con SameSite=Lax o SameSite=Strict. Ahora, esto se considera una 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 actualiza a los usuarios a la versión segura cuando se envía el formulario de acceso o salida.

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

El envío de un formulario en varios esquemas a partir de un formulario de la versión HTTP no segura del sitio que se envía a la versión HTTPS segura Se bloquearon las cookies SameSite=Strict y SameSite=Lax, y SameSite=None; se permiten las cookies seguras.
Envío de formulario entre esquemas 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 Problema de las Herramientas para desarrolladores incluirá problemas de Schemeful Same-Site. Es posible que veas los siguientes problemas destacados en tu sitio.

Problemas de navegación:

  • "Migrar por completo a HTTPS para seguir recibiendo cookies en solicitudes del mismo sitio": una advertencia de que la cookie se bloqueará en una versión futura de Chrome.
  • "Migrar por completo a HTTPS para que se envíen cookies en solicitudes del mismo sitio": una advertencia de que la cookie se bloqueó.

Problemas con la carga de subrecursos:

  • "Migrar por completo a HTTPS para seguir enviando cookies a subrecursos del mismo sitio" o "Migrar por completo a HTTPS para seguir permitiendo que los subrecursos del mismo sitio configuren cookies": Advertencia de que la cookie se bloqueará en una versión futura de Chrome.
  • "Migrar por completo a HTTPS para que se envíen cookies a subrecursos del mismo sitio" o "Migrar completamente a HTTPS para permitir que los subrecursos del mismo sitio puedan establecer cookies": advertencias de que se bloqueó la cookie. Esta última advertencia también puede aparecer cuando publicas un formulario.

Puedes obtener más información en Sugerencias de prueba y depuración para Schemeful Same-Site.

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

  • "La cookie cookie_name se tratará pronto como cookie de varios sitios en http://site.example/ porque el esquema no coincide".
  • "Se trató a la cookie cookie_name como entre sitios contra http://site.example/ porque el esquema no coincide".

Preguntas frecuentes

Mi sitio ya está completamente disponible en HTTPS. ¿Por qué veo problemas en las Herramientas para desarrolladores de mi navegador?

Es posible que algunos de tus vínculos y subrecursos sigan dirigiendo a URLs no seguras.

Una forma de solucionar este problema es usar HTTP de Seguridad de Transporte Estricta (HSTS) y la directiva includeSubDomain. Con HSTS + includeSubDomain, incluso si una de tus páginas incluye por error 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 tus usuarios, si no puedes hacerlo por tu cuenta, te sugerimos que consultes con tu proveedor de hosting para ver si puede ofrecer esa opción. Si alojas por tu cuenta, Let's Encrypt proporciona una serie de herramientas para instalar y configurar un certificado. También puedes investigar si mueves tu sitio detrás de una CDN o algún otro proxy que pueda proporcionar la conexión HTTPS.

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

  • En los casos en que solo se bloquean las cookies SameSite=Strict, puedes reducir la protección a Lax.
  • En los casos en que se bloqueen las cookies Strict y Lax, y se envíen las cookies a (o se establezcan desde) una URL segura, puedes reducir las protecciones a None.
    • Esta solución fallará si la URL a la que envías 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 configuren 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 especifico un atributo SameSite?

Las cookies sin un atributo SameSite se tratan como si especificaran SameSite=Lax, y el mismo comportamiento de esquema cruzado también se aplica a estas cookies. Ten en cuenta que todavía se aplica la excepción temporal a los métodos no seguros. Consulta la mitigación de Lax + POST en las Preguntas frecuentes de SameSite de Chromium para obtener más información.

¿Cómo se ven afectados los WebSockets?

Las conexiones de WebSocket se considerarán del mismo sitio si tienen la misma seguridad que la página.

Mismo sitio:

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

Varios sitios:

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

Foto de Julissa Capdevilla en Unsplash