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