Qué se rompe de verdad con SameSite Lax vs Strict vs None

¿Cuál es la diferencia entre SameSite Lax vs Strict vs None?

Los navegadores leen SameSite Lax vs Strict vs None como tres respuestas a una misma pregunta: qué peticiones cross-site pueden llevar esta cookie. El RFC 6265bis da las tres en un solo párrafo de la sección 4.1.2.7: "If the 'SameSite' attribute's value is 'Strict', the cookie will only be sent along with 'same-site' requests. If the value is 'Lax', the cookie will be sent with same-site requests, and with 'cross-site' top-level navigations, as described in Section 5.6.7.1. If the value is 'None', the cookie will be sent with same-site and cross-site requests."

El borrador en vigor es draft-ietf-httpbis-rfc6265bis-22, con fecha del 1 de diciembre de 2025, editado por Bingler, West y Wilander, y marcado como "Obsoletes: 6265 (if approved)". El atributo limita el alcance por sitio en lugar de por origen, así que https://www.site.example y https://api.site.example son el mismo sitio, y si dos hosts comparten sitio lo decide la lista de sufijos públicos y no solo el dominio registrable.

¿Qué permite Lax que Strict no permite?

Lax permite exactamente una clase extra de petición: una navegación de nivel superior cross-site que usa un método HTTP seguro. El RFC enuncia la excepción y su propósito a la vez, y llama a Lax "a drop-in mechanism that mitigates the risk of CSRF attacks" que "sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a 'safe' (in the [HTTP] sense) HTTP method."

MDN lo convierte en la prueba que aplicas en la práctica. Una navegación de nivel superior "essentially means that the request causes the URL shown in the browser's address bar to change", lo que incluye un enlace pulsado, una asignación a document.location y el envío de un <form>, y excluye "requests made using the fetch() API, or requests for subresources from <img> or <script> elements, or navigations inside <iframe> elements." La otra mitad, la del método seguro, "excludes POST, PUT, and DELETE."

El RFC es honesto sobre lo que Lax no te compra. "Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like POST), but does not offer a robust defense against CSRF as a general category of attack", ya que "Attackers can still pop up new windows or trigger top-level navigations in order to create a 'same-site' request".

¿Cuál es el valor por defecto de SameSite documentado por Chrome?

Chrome trata una cookie sin atributo SameSite como Lax, y documenta una excepción deliberada. La propia referencia de Google enuncia la regla: "If you send a cookie without specifying its SameSite attribute, the browser treats that cookie as if it were set to SameSite=Lax." La misma página añade la excepción en un aviso: "Chrome's default behavior is slightly more permissive than an explicit SameSite=Lax, because it lets sites send some cookies on top-level POST requests. For details, see the blink-dev announcement. This is intended as a temporary mitigation."

Esa página lleva fecha de última actualización del 7 de mayo de 2019 y una tabla de soporte que enumera Chrome 80 y Edge 86 para el cambio de valor por defecto, Firefox detrás de un flag y Safari sin soporte. El IETF ha formalizado desde entonces la excepción que Chrome llama temporal. El RFC 6265bis la nombra "Lax-allowing-unsafe" y la especifica: los agentes de usuario "MAY apply 'Lax-allowing-unsafe' enforcement only to cookies that did not explicitly specify a SameSite attribute", "SHOULD restrict the enforcement to cookies which were created recently", y "Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit." MDN da la misma cifra desde el lado del navegador: bajo un Lax por defecto, "cookies are also included in POST requests, as long as they were set no more than two minutes before the request was made."

De ahí se siguen dos consecuencias, y las dos sorprenden. Escribir SameSite=Lax de forma explícita es más estricto que no escribir nada, porque el RFC aplica Lax-allowing-unsafe solo a las cookies cuyo flag quedó en "Default" por ausencia. Y "Lax-allowing-unsafe is not a distinct value of the SameSite attribute", así que no hay ninguna cadena que puedas enviar para pedirlo.

La especificación trata una errata de la misma manera. "If the 'SameSite' attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to 'Lax'." Una cookie enviada con SameSite=Laxx no se rechaza; se trata en silencio como si no estuviera puesta.

¿Por qué SameSite=None tiene que llevar Secure?

Una cookie que declara SameSite=None sin Secure se tira, y el RFC pone eso en el algoritmo de almacenamiento en lugar de en un consejo. El paso 19 de la sección 5.7 dice: "If the cookie's 'same-site-flag' is 'None', abort this algorithm and ignore the cookie entirely unless the cookie's secure-only-flag is true."

La referencia de Google dice lo mismo a los desarrolladores, "When you create cross-site cookies using SameSite=None, you must also set them to Secure for the browser to accept them", y da la cabecera completa:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

La redacción de MDN es igual de seca: para None, "The Secure attribute must also be set when using this value." No hay ningún aviso en la consola que la mayoría lea como un aviso, porque la cookie sencillamente nunca se almacena. Si una integración cross-site funciona en tu máquina y falla en producción, comprueba primero si la respuesta puso SameSite=None sobre HTTP sin cifrar.

Partitioned se apoya encima de esto, no en su lugar. Los navegadores aceptan ese atributo solo junto a SameSite=None, algo que se cubre en cómo las cookies particionadas CHIPS dan a cada sitio su propio tarro.

¿Qué se rompe en cada modo?

El RFC ilustra el fallo de Strict con un escenario en lugar de con una regla. Un usuario que lee el correo en https://site.example pulsa un enlace a https://projects.example/secret/project: "if https://projects.example has marked their session cookies as SameSite=Strict, then this cross-site navigation won't send them along with the request. https://projects.example will render a 404 error to avoid leaking secret information, and the user will be quite confused." Strict hace que todo enlace entrante desde buscadores, correo, chat y redes sociales parezca una visita sin sesión en el primer pintado.

Su remedio prescrito son dos cookies en lugar de una, "one conceptually granting 'read' access, another granting 'write' access. The latter could be marked as SameSite=Strict, and its absence would prompt a reauthentication step before executing any non-idempotent action. The former could be marked as SameSite=Lax."

Lax rompe un conjunto más estrecho de cosas, y el RFC nombra el más afilado: "the concluding step of a login flow may involve a cross-site top-level POST request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login." Bajo Lax explícito esa cookie queda excluida por el método, "resulting in an unrecoverable failure of the whole login flow." El inicio de sesión único y los saltos de vuelta de un pago fallan igual.

None no rompe nada por regla y todo por política. El RFC identifica los casos que lo necesitan, "content intended for embedding in cross-site contexts (social networking widgets or commenting services, for instance) will not have access to same-site cookies. Cookies which are required in these situations should be marked with SameSite=None", y añade que "some forms of Single-Sign-On might require cookie-based authentication in a cross-site context". Una cookie SameSite=None; Secure es una cookie de terceros en todos los sentidos que le importan a los controles de privacidad de un navegador, así que hereda todas las restricciones que esos controles aplican. Esa herencia es la historia completa en solo el dominio decide entre cookies propias y de terceros y en qué restringe de verdad el límite de 7 días de cookies de Safari.

¿Puede una respuesta cross-site poner una cookie Lax o Strict?

No, y esta regla es independiente de la entrega. La sección 4.1.2.7 afirma que "The 'SameSite' attribute affects cookie creation as well as delivery. Cookies which assert 'SameSite=Lax' or 'SameSite=Strict' cannot be set in responses to cross-site subresource requests, or cross-site nested navigations. They can be set along with any top-level navigation, cross-site or otherwise."

Así que un widget incrustado que se carga en un <iframe> dentro de la página de otro no puede escribir una cookie Lax en absoluto, sean cuales sean sus intenciones. La única cookie que puede escribir es SameSite=None; Secure. Los scripts de analítica servidos desde un dominio de proveedor compartido chocan con esto constantemente, que es una de las razones por las que alojar el script en primera parte y la decoración de enlaces que Apple persigue pasaron al centro del diseño de la medición.

Preguntas frecuentes

¿Qué valor de SameSite debería usar una cookie de sesión?

Lax para una cookie de sesión que tiene que sobrevivir a un enlace entrante, ya que el RFC llama a Lax un "drop-in mechanism that mitigates the risk of CSRF attacks". Strict para cualquier cosa que proteja una acción que cambia estado, siguiendo el patrón de dos cookies del RFC, donde de la mitad Strict su "absence would prompt a reauthentication step before executing any non-idempotent action."

¿Omitir SameSite es lo mismo que escribir SameSite=Lax?

En Chrome no. Google documenta el valor por defecto como más permisivo: "lets sites send some cookies on top-level POST requests." El RFC 6265bis restringe ese comportamiento Lax-allowing-unsafe a "cookies that did not explicitly specify a SameSite attribute", con un límite de edad recomendado de "2 minutes or less". Escribir el atributo te da un comportamiento más estricto que dejarlo fuera.

¿SameSite=None exige HTTPS?

Sí, indirectamente, porque exige Secure y las cookies Secure están confinadas a protocolos seguros. El paso 19 del RFC 6265bis descarta la cookie sin más: ignórala "unless the cookie's secure-only-flag is true."

¿SameSite detiene el CSRF por sí solo?

No. El RFC dice que Lax "does not offer a robust defense against CSRF as a general category of attack" y dirige a los desarrolladores a "more completely mitigate CSRF through a session management mechanism". La guía de Google añade que "Neither Strict nor Lax is a complete solution for your site's security."

¿Qué pasa si envío un valor de SameSite inválido?

Se trata como si no hubieras enviado nada. Según la sección 4.1.2.7, un valor "other than these three known keywords" recibe "a default enforcement mode that is equivalent to 'Lax'", y el algoritmo de almacenamiento pone el same-site-flag de la cookie en "Default". Las mayúsculas no importan, ya que el RFC compara "None", "Strict" y "Lax" sin distinguirlas.

¿SameSite lo decide el dominio o el sitio?

El sitio, que es más amplio que el origen y más estrecho que el dominio. Los subdominios de un mismo sitio registrable son same-site entre sí, y la referencia de Google señala el límite que pilla a la gente: la lista de sufijos públicos "doesn't just depend on top-level domains like .com, but can also include services like github.io", así que your-project.github.io y my-project.github.io son sitios distintos.

¿Por qué se rompen los enlaces de correo o de búsqueda con SameSite=Strict?

La RFC describe exactamente este caso: un usuario que lee su correo hace clic en un enlace hacia un sitio con cookies de sesión SameSite=Strict, y la navegación cross-site no envía esas cookies. El sitio de destino muestra un error 404 para no filtrar datos, y el usuario ve lo que parece una página sin sesión iniciada en la primera carga. La solución que propone la RFC son dos cookies en vez de una, donde solo la cookie de escritura se marca como Strict y la de lectura como Lax.

¿Por qué falla un flujo de login con SameSite=Lax?

Algunos flujos de login terminan con un POST cross-site de nivel superior hacia un endpoint que espera una cookie creada hace poco con datos de la transacción. Una cookie con SameSite=Lax explícito queda excluida de esa petición porque POST no es un método seguro, lo que la RFC describe como "unrecoverable failure of the whole login flow". El inicio de sesión único y los retornos de pago fallan por el mismo motivo.

¿Puede un widget en un iframe cross-site poner una cookie Lax?

No. La sección 4.1.2.7 establece que las cookies con SameSite=Lax o SameSite=Strict no pueden ponerse en respuestas a peticiones cross-site de subrecursos ni a navegaciones anidadas cross-site, lo que incluye un iframe incrustado en la página de otro sitio. La única cookie que ese widget puede poner es SameSite=None con Secure.

¿Qué relación tiene el atributo Partitioned con SameSite=None?

Partitioned se añade sobre SameSite=None en vez de sustituirlo. Los navegadores solo aceptan el atributo Partitioned junto con SameSite=None, que es como CHIPS le da a cada sitio su propio frasco de cookies sin dejar de exigir None y Secure.