What is SameSite Cookie Attribute?
Definition
SameSite is a Set-Cookie attribute that controls whether a cookie is sent with requests initiated from another site. Strict sends it only on same-site requests, Lax also allows top-level navigations using safe methods, and None sends it everywhere but requires Secure. It is an important layer of defence against cross-site request forgery (CSRF), though not a complete defence on its own.
Also known as: SameSite, SameSite=Lax, SameSite=Strict, SameSite=None
The problem it was designed to solve
Browsers attach a domain's cookies to every request going to that domain. For years it did not matter who started the request: your own page, or a form or image tag on some other site. That is the weakness CSRF relies on, since a page on another site could fire a request at yours and the browser would helpfully include the user's session cookie. SameSite gives the server a way to say “do not attach this cookie to cross-site requests”.
Strict, Lax and None
| Value | When the cookie is sent | Typical use |
|---|---|---|
Strict | Only on requests initiated by the same site. Not even on the first request after following a link from another site. | High-risk action cookies, admin areas |
Lax | Same-site requests, plus cross-site top-level navigations that use a safe method such as GET | Most session cookies |
None | Always; the Secure attribute is mandatory | Widgets embedded on other sites, cross-site integrations |
Set-Cookie: session=a3f9c1; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: widget_theme=dark; Path=/; Secure; SameSite=NoneNote that “site” is broader than “origin”: it is the scheme plus the registrable domain, so shop.example.com and blog.example.com are the same site. SameSite therefore offers no protection against requests from your own subdomains; a compromised or abandoned subdomain is still same-site.
Browser defaults are not uniform
What happens when the attribute is missing depends on the browser. According to MDN's compatibility data, Chromium-based browsers treat cookies without SameSite as Lax (Chrome since version 80, Edge since 86). Firefox only does so behind a preference, and Safari does not apply a Lax default. Chromium's default is also slightly looser than an explicit Lax: a freshly set cookie may still be sent on cross-site POST requests within two minutes of being set. The practical rule: never rely on the default; set SameSite explicitly on every cookie.
The payment redirect surprise
Teams that tighten SameSite often discover the change in their checkout. During 3D Secure authentication the customer confirms the payment on their bank's page, and the bank commonly sends them back to the shop with a cross-site POST. A Strict or Lax session cookie is not included, so the shop thinks the customer is logged out and cannot match the order. The usual fix is not to loosen the session cookie to None, but to make the return endpoint work without the session, using the order reference and signed parameters.
Products that run inside iframes on other people's sites, such as chat, comments or payment widgets, have no choice but SameSite=None; Secure, and those cookies are additionally subject to browsers' third-party cookie restrictions.
Where it fits in your defences
SameSite is a strong extra layer against CSRF, but it does not fully replace anti-CSRF tokens or checking the Origin header: older browsers, same-site subdomains and state-changing GET endpoints all leave gaps. A sensible baseline for session cookies is Secure; HttpOnly; SameSite=Lax, where HttpOnly hides the cookie from JavaScript and SameSite limits which requests carry it.