SameSite Cookies: por qué algunas cookies han dejado de funcionar

Con la publicación de Chrome 84, el nuevo comportamiento de las cookies sin atributo SameSite ha llegado para quedarse, y el resto de navegadores le seguirá de cerca. Te contamos cuales son estos cambios y cómo detectarlos.

Puede que estos días te haya dejado de funcionar correctamente una aplicación web, algún script de analítica personalizado, un entorno de desarrollo sin certificado SSL o ese sitio al que accedes con un login externo de otra aplicación que tenéis en la empresa. Si eres usuario de Google Chrome, lo más probable es que sea por su nuevo comportamiento por defecto ante las cookies sin atributo SameSite.

Si esto te ha pasado, se siente ?‍♂️?. No seré yo quien te prive de usar un navegador como Firefox donde esto (todavía) no pasa, aunque creo que en este caso el toque de atención a desarrolladores por parte del equipo de Chrome es bueno, y me gustaría explicarte por qué.

El atributo SameSite

Antes de nada, me gustaría hacer un breve resumen y explicación de qué son tanto el atributo SameSite como el Secure.

Tal y como se explican en MDN:

• SameSite=<samesite-value>: asegura que una cookie no debe ser enviada en peticiones cross_site, proporcionando alguna protección contra ataques CSRF.
  • Strict: el navegador envía la cookie sólo para las peticiones same-site (esto es, peticiones que se originan desde el mismo sitio que creó la cookie). Si la petición se originó desde una URL diferente a la actual, no se envían las cookies con el atributo SameSite=Strict.
  • Lax: la cookie no se envía en peticiones cross-site, como llamadas para cargar imágenes o frames, pero se envía cuando un usuario accede a la URL desde un site externo, por ejemplo al seguir un enlace.
  • None: el navegador envía la cookie en peticiones same-site y cross-site.
• Secure: una cookie con este atributo sólo se envía al servidor cuando la petición se hace usando el protocolo https.

¿Qué diferencia práctica existe entre los modos Strict y Lax?

Si en una web haces click en un enlace a un documento de una web que requiera que hayas hecho login, y ese sitio tiene declarada su cookie como Strict, no podrás acceder al recurso hasta que vuelvas a hacer login. Sí, aunque tengas la sesión abierta en otra pestaña, porque has accedido a esa web desde un enlace externo y esto ha hecho que el navegador bloquee el envío de tus cookies. Con el modo Lax las cookies sí se enviarían al hacer click en el enlace, pero tendríamos el mismo problema si intentáramos cargar el recurso usando un iframe o un img si lo que queríamos compartir era una imagen. Esto sucede porque con Lax sólo se envían las cookies en peticiones top-level, aquellas que generan un cambio de URL en el navegador.

El atributo SameSite está ampliamente soportado por los navegadores, que empezaron en algunos casos en 2016. Los que lo soportan, actúan según lo esperado siempre que este atributo (y el Secure) estén correctamente configurados.

Nuevo comportamiento

Pese a que estas medidas de seguridad llevan mucho tiempo disponibles para los desarrolladores web, no es que su adopción haya sido rápida precisamente. Para propiciar la adopción del atributo SameSite los navegadores llevan tiempo preparando la transición hacia un nuevo comportamiento de las cookies que permita aumentar la seguridad y tu privacidad en la red. En Mayo de 2019 se lanzaba la propuesta Incrementally Better Cookies, que propone 2 cosas:

1. Tratar las cookies como SameSite=Lax por defecto. Esto es: si el atributo SameSite no se establece o no es válido, el valor predeterminado es SameSite=Lax.
2. Las cookies marcadas como SameSite=None deben también ser marcadas como Secure para habilitar su transferencia entre sitios.

Todos los navegadores han empezado a adoptar estas medidas de comportamiento por defecto, pero es Google Chrome quien ha estado llevando la iniciativa, con un roadmap y un timeline detallado. La transición en el caso de este navegador ha abarcado desde octubre de 2019 hasta agosto de 2020, con la publicación de Chrome 84, incluyendo una pequeña moratoria por culpa de la crisis sanitaria.

? Nota: en realidad Chrome todavía hace una excepción para cookies sin atributo SameSite establecidas «hace menos de 2 minutos», permitiendo su envío con peticiones POST top-level cross-site. Este caso, conocido como Lax + POST, será deshabilitado en un futuro, aunque todavía no hay fecha.

Podemos comprobar el nuevo comportamiento de las cookies en nuestros navegadores con una herramienta como SameSite ? Sandbox.

En ella veremos que Chrome es el único a día de hoy que cumple todos los casos de uso del nuevo comportamiento, notablemente rechazando aquellas cookies con SameSite=None sin el atributo Secure, que es precisamente lo que podría ocasionar la rotura de alguna web o integración.

El resto de navegadores no implementan todavía los bloqueos en la creación de cookies que suponen estas nuevas medidas de seguridad, por lo que todavía son posibles los escenarios escribir una cookie legible por terceros sin el atributo Secure.

Por ahora estos navegadores sólo ofrecen advertencias para desarrolladores, que indican que si no se adaptan a los nuevos cambios, las cookies afectadas dejarán de funcionar en una futura versión:

El resto de navegadores basados en Chromium/Blink  proporcionan información adicional al encontrar cookies problemáticas:

Conclusiones

En definitiva, el nuevo comportamiento pone el acelerador en la adopción de unas medidas de seguridad básicas que llevaban tiempo estando disponibles. Y reforzar la seguridad en internet siempre es buena idea.

¿Qué deberías hacer? Si tienes webs que hagan uso de cookies propias o tengan social-login/sign-on de terceros (uno de los típicos escenarios que ha estado dando fallos) no estaría de más que comprobaras cuanto antes si tiene todas tus cookies en orden en caso de que todavía no lo hayas hecho. Tus usuarios de Chrome y «en breve» todos los habidos y por haber te lo agracederán.

The Cookies They Are a-Changin’ ?