What Actually Breaks in SameSite Lax vs Strict vs None

What is the difference between SameSite Lax vs Strict vs None?

Browsers read SameSite Lax vs Strict vs None as three answers to one question: which cross-site requests may carry this cookie. RFC 6265bis gives all three in a single paragraph of section 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."

The draft in force is draft-ietf-httpbis-rfc6265bis-22, dated 1 December 2025, edited by Bingler, West and Wilander, and marked "Obsoletes: 6265 (if approved)". The attribute limits scope by site rather than by origin, so https://www.site.example and https://api.site.example are the same site, and whether two hosts share a site is decided by the public suffix list rather than by the registrable domain alone.

What does Lax allow that Strict does not?

Lax allows exactly one extra class of request: a cross-site top-level navigation that uses a safe HTTP method. The RFC states the carve-out and its purpose together, calling Lax "a drop-in mechanism that mitigates the risk of CSRF attacks" that "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 turns that into the test you apply in practice. A top-level navigation "essentially means that the request causes the URL shown in the browser's address bar to change", which includes a clicked link, an assignment to document.location and a <form> submission, and excludes "requests made using the fetch() API, or requests for subresources from <img> or <script> elements, or navigations inside <iframe> elements." The safe-method half "excludes POST, PUT, and DELETE."

The RFC is honest about what Lax does not buy you. "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", since "Attackers can still pop up new windows or trigger top-level navigations in order to create a 'same-site' request".

What is Chrome's documented default for SameSite?

Chrome treats a cookie with no SameSite attribute as Lax, and documents one deliberate exception. Google's own reference states the rule: "If you send a cookie without specifying its SameSite attribute, the browser treats that cookie as if it were set to SameSite=Lax." The same page adds the exception in a caution box: "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."

That page carries a last-updated date of 7 May 2019 and a browser support table listing Chrome 80 and Edge 86 for the default change, Firefox behind a flag, and Safari not supported. The IETF has since formalised the carve-out Chrome calls temporary. RFC 6265bis names it "Lax-allowing-unsafe" and specifies it: user agents "MAY apply 'Lax-allowing-unsafe' enforcement only to cookies that did not explicitly specify a SameSite attribute", they "SHOULD restrict the enforcement to cookies which were created recently", and "Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit." MDN states the same number from the browser side: under a defaulted Lax, "cookies are also included in POST requests, as long as they were set no more than two minutes before the request was made."

Two consequences follow, and both surprise people. Writing SameSite=Lax explicitly is stricter than writing nothing, because the RFC applies Lax-allowing-unsafe only to cookies whose flag was set to "Default" by absence. And "Lax-allowing-unsafe is not a distinct value of the SameSite attribute", so there is no string you can send to request it.

The specification also handles a typo the same way. "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'." A cookie sent with SameSite=Laxx is not rejected; it is silently treated as unset.

Why must SameSite=None carry Secure?

A cookie asserting SameSite=None without Secure is thrown away, and the RFC puts that in the storage algorithm rather than in advice. Step 19 of section 5.7 reads: "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."

Google's reference says the same to developers, "When you create cross-site cookies using SameSite=None, you must also set them to Secure for the browser to accept them", and gives the full header:

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

MDN's wording is equally flat: for None, "The Secure attribute must also be set when using this value." There is no warning in the console flow that reads as a warning to most people, because the cookie is simply never stored. If a cross-site integration works on your machine and fails in production, check whether the response set SameSite=None over plain HTTP first.

Partitioned layers on top of this, not instead of it. Browsers accept that attribute only alongside SameSite=None, which is covered in how CHIPS partitioned cookies give each site its own jar.

What breaks in each mode?

The RFC illustrates the Strict failure with a scenario rather than a rule. A user reading mail at https://site.example clicks a link to 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 makes every inbound link from search, mail, chat and social look like a logged-out visit on first paint.

Its prescribed fix is two cookies rather than one, "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 breaks a narrower set of things, and the RFC names the sharpest one: "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." Under explicit Lax that cookie is excluded on method grounds, "resulting in an unrecoverable failure of the whole login flow." Single sign-on and payment return hops fail the same way.

None breaks nothing by rule and everything by policy. The RFC identifies the cases that need it, "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", and adds that "some forms of Single-Sign-On might require cookie-based authentication in a cross-site context". A SameSite=None; Secure cookie is a third-party cookie in every sense that matters to a browser's privacy controls, so it inherits every restriction those controls apply. That inheritance is the whole story in only the domain decides first-party against third-party cookies, and in what the Safari 7 day cookie limit actually restricts.

Can a cross-site response set a Lax or Strict cookie?

No, and this rule is separate from delivery. Section 4.1.2.7 states that "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."

So an embedded widget loaded in an <iframe> on somebody else's page cannot write a Lax cookie at all, whatever its intentions. The only cookie it can write is SameSite=None; Secure. Analytics scripts served from a shared vendor domain hit this constantly, which is one of the reasons first-party script hosting and the link decoration that Apple targets moved to the centre of measurement design.

Frequently asked questions

Which SameSite value should a session cookie use?

Lax for a session cookie that has to survive an inbound link, since the RFC calls Lax a "drop-in mechanism that mitigates the risk of CSRF attacks". Strict for anything guarding a state-changing action, following the RFC's two-cookie pattern where the Strict half's "absence would prompt a reauthentication step before executing any non-idempotent action."

Is omitting SameSite the same as writing SameSite=Lax?

Not in Chrome. Google documents the default as more permissive: it "lets sites send some cookies on top-level POST requests." RFC 6265bis restricts that Lax-allowing-unsafe behaviour to "cookies that did not explicitly specify a SameSite attribute", with a recommended age limit of "2 minutes or less". Writing the attribute out gives you stricter behaviour than leaving it off.

Does SameSite=None require HTTPS?

Yes, indirectly, because it requires Secure and Secure cookies are confined to secure protocols. RFC 6265bis step 19 discards the cookie outright: ignore it "unless the cookie's secure-only-flag is true."

Does SameSite stop CSRF on its own?

No. The RFC says Lax "does not offer a robust defense against CSRF as a general category of attack" and directs developers to "more completely mitigate CSRF through a session management mechanism". Google's guidance adds that "Neither Strict nor Lax is a complete solution for your site's security."

What happens if I send an invalid SameSite value?

It is treated as though you sent nothing. Per section 4.1.2.7, a value "other than these three known keywords" gets "a default enforcement mode that is equivalent to 'Lax'", and the storage algorithm sets the cookie's same-site-flag to "Default". Case does not matter, since the RFC matches "None", "Strict" and "Lax" case-insensitively.

Is SameSite decided by domain or by site?

By site, which is broader than origin and narrower than domain. Subdomains of one registrable site are same-site with each other, and Google's reference points at the boundary that catches people out: the public suffix list "doesn't just depend on top-level domains like .com, but can also include services like github.io", so your-project.github.io and my-project.github.io are separate sites.

Why do links from email or search break under SameSite=Strict?

The RFC walks through this exact case: a user reading mail clicks a link to a site with SameSite=Strict session cookies, and the cross-site navigation does not carry those cookies along. The destination renders a 404 to avoid leaking data, and the user sees what looks like a logged-out page on first load. The RFC's fix is two cookies instead of one, with only the write-access cookie marked Strict and the read-access cookie marked Lax.

Why does a login flow fail under SameSite=Lax?

Some login flows finish with a cross-site top-level POST to a callback endpoint that expects a recently created cookie holding transactional state. An explicit SameSite=Lax cookie is excluded from that request because POST is not a safe method, which the RFC describes as "an unrecoverable failure of the whole login flow." Single sign-on and payment return hops fail for the same reason.

Can a cross-site iframe widget set a Lax cookie?

No. Section 4.1.2.7 states that cookies asserting SameSite=Lax or SameSite=Strict cannot be set in responses to cross-site subresource requests or cross-site nested navigations, which covers an iframe embedded on someone else's page. The only cookie such a widget can write is SameSite=None with Secure.

What does the Partitioned attribute have to do with SameSite=None?

Partitioned layers on top of SameSite=None rather than replacing it. Browsers only accept the Partitioned attribute alongside SameSite=None, which is how CHIPS gives each site its own cookie jar while keeping the None and Secure requirements in place.