Schemeful SameSite

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

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Schemeful Same-Site modifica la definición de un sitio (web) de solo el 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 está completamente actualizado a HTTPS, no tienes que preocuparte por nada. Nada cambiará para ti.

Si aún no actualizaste por completo tu sitio web, esta debería ser la prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio pasan de HTTP a HTTPS, algunos de esos casos de uso comunes y el comportamiento de las cookies SameSite asociadas se describen más adelante en este artículo.

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 de estado de Chrome.
  • En Firefox 79, configura network.cookie.sameSite.schemeful como true a través de about:config. Realiza un seguimiento del progreso con el problema de Bugzilla issue.

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 aún brinda una oportunidad para que los atacantes de la 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.

Casos de uso comunes entre esquemas

Anteriormente, la navegación entre versiones de un sitio web entre esquemas (por ejemplo, la vinculación de http://sitio.ejemplo a https://sitio.ejemplo) permitía enviar SameSite=Strict cookies. Ahora, esto se trata como una navegación entre sitios, lo que significa que se bloquearán las cookies SameSite=Strict.

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 bloquean las cookies con SameSite=Strict, y se permiten las cookies con SameSite=Lax y SameSite=None; Secure.
Navegación entre esquemas de HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ✓ Permitido ✓ Permitido
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Carga de subrecursos

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

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

Anteriormente, la carga de un subrecurso entre esquemas en una página permitía enviar o configurar cookies SameSite=Strict o SameSite=Lax. Ahora, 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, todas las cookies se bloquearán en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.

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

Publicación de un formulario

Anteriormente, la publicación entre versiones de un sitio web entre esquemas permitía enviar cookies configuradas con SameSite=Lax o SameSite=Strict. Ahora, esto se trata como una publicación entre sitios: solo se pueden enviar cookies SameSite=None. Es posible que te encuentres con este caso de uso en sitios que presentan la versión no segura de forma predeterminada, pero actualizan a los usuarios a la versión segura cuando envían 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), todas las cookies se bloquearán en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.

Envío de un formulario entre esquemas que se produce cuando se envía un formulario de la versión HTTP no segura del sitio a la versión HTTPS segura. Se bloquean las cookies con SameSite=Strict y SameSite=Lax, y se permiten las cookies con SameSite=None; Secure.
Envío de formularios entre esquemas de HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Permitido ⛔ 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 para tu sitio.

Problemas de navegación:

  • "Migra por completo a HTTPS para seguir enviando cookies en solicitudes del mismo sitio": Una advertencia de que la cookie se bloqueará en una versión futura de Chrome.
  • "Migra por completo a HTTPS para enviar cookies en solicitudes del mismo sitio": Una advertencia de que la cookie se bloqueó.

Problemas de carga de subrecursos:

  • "Migra por completo a HTTPS para seguir enviando cookies a subrecursos del mismo sitio" o "Migra por completo a HTTPS para seguir permitiendo que los subrecursos del mismo sitio configuren cookies": Advertencias de que la cookie se bloqueará en una versión futura de Chrome.
  • "Migra por completo a HTTPS para enviar cookies a subrecursos del mismo sitio" o "Migra por completo a HTTPS para permitir que los subrecursos del mismo sitio configuren cookies": Advertencias de que la cookie se bloqueó. La última advertencia también puede aparecer cuando se publica un formulario.

Hay más detalles disponibles en Sugerencias para probar y depurar 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 una cookie entre sitios en relación con http://site.example/ porque el esquema no coincide".
  • "La cookie cookie_name se trató como una cookie entre sitios en relació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 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 includeSubDomain directiva. Con HSTS + 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 tus usuarios, si no puedes hacerlo por tu cuenta, te sugerimos que hables con tu proveedor de hosting para ver si puede ofrecer esa opción. Si usas alojamiento propio, entonces Let's Encrypt proporciona varias herramientas para instalar y configurar un certificado. También puedes investigar cómo trasladar tu sitio detrás de una CDN o de otro proxy que pueda proporcionar la conexión HTTPS.

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

  • En los casos en los que solo se bloquean las cookies SameSite=Strict, puedes reducir la protección a Lax.
  • En los casos en los que se bloquean las cookies Strict y Lax, y tus cookies se envían a una URL segura (o se configuran desde ella), puedes reducir las protecciones a None.
    • Esta solución alternativa 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, se eliminarán por completo las cookies de terceros.

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

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

¿Cómo se ven afectados los WebSockets?

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

Mismo sitio:

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

Entre sitios:

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