Schemeful SameSite

La definición de "mismo sitio" está evolucionando para incluir el esquema de URL, de manera 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 siempre que sea posible o lee más detalles sobre los valores de atributo de SameSite que se necesitan.

Schemeful Same-Site modifica la definición de un sitio (web) desde el dominio registrable al esquema y al dominio registrable. Puedes encontrar más detalles y ejemplos en Información sobre "same-site" y "same-origin".

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

Si aún no actualiza completamente su sitio web, esta debería ser la prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio pasarán entre HTTP y HTTPS, algunas de esas situaciones comunes y el comportamiento asociado de la cookie SameSite se describen a continuación.

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

• En Chrome 86, habilita about://flags/#schemeful-same-site. Realiza un seguimiento del progreso en la página Estado de Chrome.
• En Firefox 79, configura network.cookie.sameSite.schemeful como 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 la 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 aún 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

Navigation

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

	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 correcció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.

Antes, la carga de un subrecurso entre esquemas en una página permitía anteriormente el envío o la configuración de cookies SameSite=Strict o SameSite=Lax. Esto 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 entre sitios requieren Secure.

	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 anteriormente el envío de las cookies establecidas con SameSite=Lax o SameSite=Strict. Ahora, esto se trata como un POST entre sitios: solo se pueden enviar cookies SameSite=None. Es posible que te encuentres con esta situación en los sitios que presentan la versión no segura de forma predeterminada, pero debes actualizar a los usuarios a la versión segura cuando envíes el formulario de acceso o salida.

Al igual que con los subrecursos, si la solicitud va 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.

	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 la mensajería para desarrolladores están disponibles en Chrome y Firefox.

A partir de Chrome 86, la pestaña Issue de Herramientas para desarrolladores incluirá problemas de Schemeful SameSite. Es posible que veas los siguientes problemas destacados para tu sitio.

Problemas de navegación:

• "Migrar completamente a HTTPS para que se sigan enviando cookies en las 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 recibir 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 que las cookies se envíen a subrecursos del mismo sitio" o "Migrar completamente a HTTPS para permitir 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 las cookies se envíen a subrecursos del mismo sitio" o "Migrar completamente a HTTPS para permitir que los subrecursos del mismo sitio configuren cookies": se advierte que se bloqueó la cookie. Esta última advertencia también puede aparecer cuando se PUBLICA un formulario.

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

En Firefox 79, con network.cookie.sameSite.schemeful establecido en 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 pronto se tratará como cookie entre sitios con http://site.example/ porque el esquema no coincide".
• "La cookie cookie_name se trató 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 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 + includeSubDomain, incluso si una de tus páginas incluye un vínculo no seguro por error, 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, 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 varias herramientas para instalar y configurar un certificado. También puedes investigar si mueves el sitio detrás de una CDN o algún 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 SameSite=Strict, puedes disminuir la protección a Lax.
• En los casos en que se bloqueen las cookies Strict y Lax, y las cookies se envíen a una URL segura (o se configuren desde ella), 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 esas cookies pueden no enviarse ni configurarse mediante 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 entre esquemas 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 seguirán considerando como el mismo sitio si tienen la misma seguridad que la página.

Mismo sitio:

• wss:// conexión desde https://
• ws:// conexión desde http://

Varios sitios:

• wss:// conexión desde http://
• ws:// conexión desde https://

Foto de Julissa Capdevilla de Unsplash