flawopen.com/CSRF/Cookies SameSite
¿SameSite=Strict sustituye los tokens CSRF?
SameSite=Strict es una capa sólida del navegador para solicitudes autenticadas con cookies que se originan en otro sitio, pero no es una defensa universal contra CSRF. Los subdominios hermanos siguen contando como el mismo sitio aunque tengan orígenes distintos, y los clientes que no aplican el atributo no obtienen protección. Mantén un token CSRF u otra defensa basada en el origen de la solicitud cuando lo requiera el modelo de amenazas.
Qué hace realmente SameSite
Una cookie SameSite=Strict no se envía en solicitudes cross-site, incluido el patrón clásico de CSRF en el que otro sitio envía un formulario a tu aplicación. Esto impide que el navegador adjunte automáticamente la cookie de sesión en ese contexto. SameSite se aplica a un sitio, no a un origen: una solicitud desde un subdominio hermano puede seguir siendo same-site, así que Strict no protege contra un host hermano comprometido o no confiable. Strict también puede dejar al usuario sin autenticar al seguir un enlace externo, porque la cookie no se envía durante esa navegación.
Qué limitaciones conserva
Si la autenticación usa un bearer token que la aplicación coloca explícitamente en el encabezado Authorization, SameSite no controla ese encabezado. El comportamiento automático del navegador para las cookies es distinto. Esto no vuelve seguro automáticamente cualquier diseño: evalúa si otro mecanismo puede adjuntar credenciales automáticamente y protege los tokens contra el robo y el uso indebido.
SameSite=Lax explícito permite solicitudes same-site y navegaciones de nivel superior cross-site con un método seguro, como GET; no envía la cookie en subsolicitudes cross-site ni en navegaciones con métodos no seguros. Si se omite el atributo, se aplica el valor predeterminado del agente de usuario. En Chromium, ese valor predeterminado difiere de Lax explícito: la implementación actual permite que algunas cookies sin atributo explícito se envíen en solicitudes cross-site de nivel superior con métodos no seguros durante un máximo de 2 minutos desde su creación (Lax-allowing-unsafe). No dependas de esta compatibilidad específica del navegador como defensa CSRF. Define explícitamente el atributo deseado, prueba los clientes compatibles y nunca permitas cambios de estado mediante un método seguro.
La aplicación de SameSite depende del navegador. Un cliente que no admite o no respeta el atributo no obtiene protección. Comprueba los clientes compatibles con tu aplicación y trata SameSite como defensa en profundidad junto con un token CSRF adecuado, la validación de Origin u otra defensa principal.
Preguntas frecuentes
Consulta la guía específica sobre métodos seguros. No permitas que las acciones que cambian el estado sean accesibles mediante métodos seguros como GET; se espera que estos métodos no modifiquen el estado del servidor.