Este artículo forma parte de una serie sobre los cambios del atributo de cookies SameSite:
SameSite
Schemeful Same-Site modifica la definición de un sitio (web) de solo el dominio registrable al esquema + dominio registrable. Puedes encontrar más información y ejemplos en Información sobre "same-site" y "same-origin".
Término clave: Esto significa que la versión HTTP insegura de un sitio, por ejemplo, http://website.example, y la versión HTTPS segura de ese sitio, https://website.example, ahora se consideran entre sitios.
La buena noticia es que, si tu sitio web ya fue totalmente actualizado a HTTPS, no necesitas preocuparte por nada. Nada cambiará para ti.
Si todavía no has actualizado totalmente tu sitio web, esa debería ser tu prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio van a elegir entre HTTP y HTTPS, algunos de esos escenarios comunes y el comportamiento de las cookies SameSite asociadas se describen a continuación.
Advertencia: El plan a largo plazo es eliminar gradualmente la asistencia a cookies de terceros por completo y reemplazarlas con alternativas que preserven la privacidad. Configurar SameSite=None; Secure en una cookie para permitir que se envíe entre esquemas solo debería considerarse una solución temporal en la migración hacia el HTTPS completo.
SameSite=None; Secure
Puedes habilitar estos cambios para realizar la prueba tanto en Chrome como en Firefox.
chrome://flags/#schemeful-same-site
network.cookie.sameSite.schemeful
true
about:config
Una de las razones principales para cambiar a SameSite=Lax como la configuración predeterminada para cookies fue protegerse contra la falsificación de solicitudes entre sitios (CSRF). Sin embargo, el tráfico HTTP inseguro aún presenta una oportunidad para que los atacantes de la red falsifiquen las cookies que, luego, serán usadas en la versión HTTPS segura del sitio. Crear este límite entre sitios adicional entre esquemas proporciona una mayor defensa ante estos ataques.
SameSite=Lax
Término clave: En los siguientes ejemplos en los que las URL tienen el mismo dominio registrable, p. ej., site.example, pero diferentes esquemas, por ejemplo, http://site.example frente a https://site.example, se utiliza la denominación entre esquemas.
Navegar entre versiones entre esquemas de un sitio web (por ejemplo, establecer vínculos desde http://site.example y https://site.example) antes permitía que se enviaran cookies SameSite=Strict. Ahora, esto se trata como una navegación entre sitios, lo que significa que las cookies SameSite=Strict se bloquearán.
SameSite=Strict
SameSite=None;Secure
Advertencia: Todos los navegadores populares bloquean el contenido mixto activo como las secuencias de comando y los iframes. Además, los navegadores, incluidos Chrome y Firefox, trabajan para lograr la actualización o el bloqueo del contenido mixto pasivo.
Cualquier cambio que hagas aquí se considerará una solución temporal mientras trabajas para actualizar por completo a HTTPS.
Entre los ejemplos de subrecursos, se incluyen imágenes, iframes y solicitudes de red realizadas con XHR o Fetch.
Antes, cargar un subrecurso entre esquemas en una página habría permitido que las cookies SameSite=Strict o SameSite=Lax se enviaran o configuraran. Ahora, esto se trata de la misma forma que cualquier otro subrecurso de terceros o entre sitios, lo que significa que cualquier cookie SameSite=Strict o SameSite=Lax se bloqueará.
Además, incluso si el navegador permite que se carguen recursos de esquemas inseguros 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.
Secure
Antes, publicar entre versiones entre esquemas de un sitio permitía que las cookies configuradas con SameSite=Lax o SameSite=Strict se enviaran. Ahora, esto se trata como una publicación entre sitios: solo pueden enviarse cookies SameSite=None. Tal vez encuentres este escenario en sitios que presentan la versión insegura de manera predeterminada, pero los usuarios se actualizan a la versión segura al enviar el formulario de acceso o salida.
SameSite=None
Como ocurre con los subrecursos, si la solicitud va de un contexto seguro, p. ej., HTTPS, a uno inseguro, p. ej., HTTP, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.
Advertencia: La mejor solución aquí es asegurar que tanto la página de formulario como el destino estén en una conexión segura como HTTPS. Esto es particularmente importante si el usuario está ingresando información confidencial en el formulario.
Las herramientas para desarrolladores y la mensajería están disponibles en Chrome y Firefox.
Desde Chrome 86, la pestaña Error en DevTools incluirá errores Schemeful Same-Site. Puedes ver los siguientes errores destacados para tu sitio.
Errores de navegación:
Errores de carga de subrecursos:
Hay más información disponible en Sugerencias de pruebas y depuración para Schemeful Same-Site.
Desde Firefox 79, con network.cookie.sameSite.schemeful configurado como true mediante about:config, la consola mostrará un mensaje para los errores de Schemeful Same-Site. Tal vez veas lo siguiente en tu sitio:
cookie_name
http://site.example/
Es posible que algunos de tus vínculos y sus recursos aún apunten a URL inseguras.
Una forma de solucionar este error es usar HTTP con Seguridad de Transporte Estricta (HSTS) y la directiva includeSubDomain. Con HSTS + includeSubDomain, incluso si una de tus páginas incluye un vínculo inseguro por accidente, el navegador usará en su lugar la versión segura automáticamente.
includeSubDomain
Si bien recomendamos enfáticamente que actualices tu sitio completo a HTTPS para proteger a tus usuarios, si no puedes hacerlo solo, te sugerimos que hables con tu proveedor de hosting para ver si te ofrece esa opción. Si usas tu propio host, entonces Let's Encrypt proporciona herramientas para instalar y configurar un certificado. También puedes investigar la posibilidad de mover tu sitio a CDN o a otro proxy que pueda proporcionar la conexión HTTPS.
Si eso tampoco es posible, intenta disminuir la protección SameSite en las cookies afectadas.
Lax
Strict
None
Las cookies sin un atributo SameSite se tratan como si especificaran SameSite=Lax y el mismo comportamiento entre esquemas se aplica a ellas. Ten en cuenta que la excepción temporal para métodos poco seguros aún se aplica. Para obtener más información, consulta la mitigación Lax + POST en las preguntas frecuentes de ChromiumSameSite.
Las conexiones WebSocket aún se considerarán del mismo sitio si están en la misma seguridad que la página.
Mismo sitio:
wss://
https://
ws://
http://
Entre sitios:
Fotografía de Julissa Capdevilla en Unsplash
