SameSite Cookie Matrix
See how SameSite=Strict/Lax/None behave across cross-site flows like login and checkout.
A cookie's SameSite attribute decides whether the cookie travels along with requests that originate from other sites. The three values — Strict, Lax and None — behave differently per scenario and are easy to mix up. This tool shows an at-a-glance matrix of whether the cookie is sent for cross-site situations like clicking a link, a form POST, an iframe, or a fetch/XHR.
You can also pick a SameSite value to generate and copy a real Set-Cookie header example. To confirm how the header actually ships, inspect your response cookies with Cookie Security Check and audit the full set with Security Headers Checker.
| Cross-site scenario | Strict | Lax | None (+Secure) |
|---|---|---|---|
| Top-level navigation GET (clicking a link) | Not sent | Sent | Sent |
| Cross-site form POST | Not sent | Not sent | Sent |
| Cross-site iframe / embedded resource | Not sent | Not sent | Sent |
| Cross-site fetch / XHR | Not sent | Not sent | Sent |
Set-Cookie: session=...; SameSite=Lax; Secure; HttpOnlyThe three SameSite values
Each value limits how widely the cookie is sent on cross-site requests.
- Strict: sent only on same-site requests. Even arriving via a link from another site won't include it.
- Lax: sent only on top-level navigation GETs (clicking a link). Not sent on cross-site POST, iframe, or fetch.
- None: sent on all cross-site requests, but it must be paired with
Secure(HTTPS).
Defaults and when to use None
Modern browsers treat a cookie with no explicit SameSite as Lax by default, so most CSRF is mitigated out of the box. Reach for SameSite=None; Secure only when another site genuinely needs the cookie — payment widgets, cross-domain embeds, or third-party authentication.
- If
SameSite=Noneis set withoutSecure, modern browsers reject the cookie. - For session cookies, also add
HttpOnlyto block JavaScript access. - Example:
Set-Cookie: session=...; SameSite=Lax; Secure; HttpOnly
Which SameSite to choose per use case
The scenarios you actually hit in production, the value to pick, and why.
| Use case | Recommended | Why |
|---|---|---|
| Same-site session / CSRF defense | Lax or Strict | The cookie is withheld from cross-site POST and fetch, sharply reducing CSRF. For most ordinary web apps Lax is enough. |
| SSO / OAuth redirect that needs the cookie after cross-site navigation | Lax | The cookie is sent on top-level GET navigation, so the redirect coming back from an external identity provider works correctly. |
| Embedded third-party widget / iframe that needs cookies | None (Secure required) | Cookies must travel on iframe and cross-site requests, so None is the only option — and it must be served over HTTPS with Secure. |
| Highest CSRF safety | Strict | Not even the first request arriving from another site carries the cookie. The trade-off: inbound links can make a logged-in user appear logged out, hurting usability. |
Worked example: a payment iframe losing its session
Suppose a shop opens a third-party payment provider in an iframeat checkout, but every time the payment screen loads the user's session disappears as if they were logged out. Inspecting the response, the session cookie ships as Set-Cookie: pgsession=abc; SameSite=Lax; Secure.
- Symptom: the login state is not preserved only inside the payment
iframe. - Cause: an
iframeis a cross-site context, so aLaxcookie is not sent. (Leaving the attribute unset behaves the same, since browsers default toLax.) - Fix: change it to
Set-Cookie: pgsession=abc; SameSite=None; Secureso the cookie is sent on the cross-siteiframeand the session persists.