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
comotrue
a través deabout: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 conhttp://site.example/
porque el esquema no coincide". - "La cookie
cookie_name
se trató como entre sitios contrahttp://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 aLax
. - En los casos en que se bloqueen las cookies
Strict
yLax
, y las cookies se envíen a una URL segura (o se configuren desde ella), puedes reducir las protecciones aNone
.- 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 atributoSecure
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.
- 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
¿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 desdehttps://
ws://
conexión desdehttp://
Varios sitios:
wss://
conexión desdehttp://
ws://
conexión desdehttps://
Foto de Julissa Capdevilla de Unsplash