SameSite Cookies: Strict, Lax & None Explained
The SameSite cookie attribute controls whether a browser sends a cookie along with requests that originate from another site. It is the primary built-in defence against cross-site request forgery (CSRF): by refusing to attach a session cookie to requests coming from a different origin, the browser stops an attacker's page from acting on the user's behalf.
What is the SameSite attribute?
Standardised in the cookie specification (RFC 6265bis), SameSite is set in the Set-Cookie header. Normally a browser attaches a site's cookies to any request to that site, including ones triggered by a different website — which is exactly the behaviour CSRF abuses. SameSite lets the server say "only send this cookie when the request comes from my own site."
SameSite values
| Value | Behaviour |
|---|---|
Strict | The cookie is never sent on any cross-site request — not even when the user clicks a link from another site. Strongest, but can log users out when they arrive via external links. |
Lax | The cookie is sent on top-level navigations using safe methods (a normal GET link click) but not on cross-site POSTs, iframes, or background requests. The modern browser default and a good balance. |
None | The cookie is sent on all cross-site requests. Required for legitimate cross-site use (e.g. embedded widgets) but must be paired with Secure, or browsers reject it. |
Example Set-Cookie with SameSite
Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly; Path=/How SameSite stops CSRF
A CSRF attack works by getting a victim's browser to send an authenticated request — often a form POST — from the attacker's page. With SameSite=Lax or Strict, the browser will not attach the session cookie to that cross-site POST, so the forged request arrives unauthenticated and fails. SameSite does not replace anti-CSRF tokens, but it raises the baseline significantly and is why modern browsers default cookies to Lax.
How to check the SameSite attribute
See whether a site's cookies set SameSite (and Secure and HttpOnly) by inspecting its Set-Cookie headers with the free HTTP headers checker.
Common mistakes
SameSite=NonewithoutSecure. Browsers reject this combination, silently dropping the cookie. Always pairNonewithSecure.- Using
Stricton the main session cookie. It can log users out when they follow a link from email or another site.Laxis usually the better default. - Relying on SameSite alone for CSRF. Keep anti-CSRF tokens too; some older browsers and edge cases do not fully honour SameSite.
Related guides
SameSite is one of three cookie security flags, alongside Secure and HttpOnly. It directly defends against CSRF — see also CSRF vs SSRF.
Frequently asked questions
What is the best SameSite value?
Lax is the recommended default for session cookies: it blocks cross-site POSTs (the CSRF vector) while still letting users stay logged in when they follow a normal link to your site. Use Strict for the most sensitive cookies.
Does SameSite require HTTPS?
Only SameSite=None does — it must be combined with the Secure flag. Lax and Strict work without it, though you should use Secure anyway.
Is SameSite enough to prevent CSRF?
It is a strong mitigation but not a complete one. Keep anti-CSRF tokens on state-changing requests in addition to SameSite=Lax/Strict.