SameSite: qué protege y qué no

SameSite decide por sitio, no por origen: el esquema más el dominio registrable, sin mirar subdominios ni puerto. Para el navegador, oficina.pescadero.example y asociados.pescadero.example son orígenes distintos pero el mismo sitio, y una petición entre ellos no es «entre sitios».

Los tres valores dicen cuándo viaja la cookie hacia su sitio desde otro: Strict, nunca; Lax, solo en navegaciones de nivel superior con métodos seguros, como seguir un enlace; None, siempre, y exige Secure.

Lax no corta todo lo que viene de fuera: una navegación de nivel superior por GET lleva la cookie, porque si no, abrir el portal desde un enlace de correo obligaría a iniciar sesión cada vez. Por eso una acción que cambia algo por GET queda fuera de lo que Lax protege.

Abre cookies.txt y prueba-navegador.txt.

Como SameSite trabaja por sitio, cualquier host del mismo dominio registrable envía peticiones que el navegador considera propias. Si uno de esos hosts lo opera un tercero o publica contenido que no controla el equipo, sus páginas pueden originar acciones contra el portal con la cookie incluida. Cruza la prueba con dominios.txt.

Cuando una cookie no declara SameSite, cada navegador decide: algunos la tratan como Lax por defecto y otros no, y los comportamientos han cambiado con las versiones. Apoyarse en ese valor por defecto es apoyarse en el navegador de cada persona. Lo correcto es declarar el atributo de forma explícita en todas las cookies de sesión.

Con lo que muestran la prueba y el inventario, SameSite reduce mucho la exposición: las peticiones POST y las incrustadas desde otros sitios llegan sin cookie. Pero no cubre las acciones por GET, no separa los hosts del mismo sitio y depende del navegador. La guía de OWASP la trata como una defensa en profundidad, no como la principal.