SameSite cookies: half of the CSRF defence the browser does for you
What SameSite does
When your server sets a cookie, you can tag it with a SameSite attribute. The browser then decides whether to send that cookie on cross-site requests.
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax
| SameSite value | Behaviour |
Strict | Cookie sent ONLY when the request URL matches your site. Even clicking a link from google.com to yoursite.com arrives logged-out. |
Lax (browser default in 2026) | Sent on top-level GET navigations from other sites, NOT on cross-site POSTs / iframes / fetch. Stops most CSRF without breaking link-clicks. |
None | Sent on everything cross-site. Requires Secure. Use only for embeds you genuinely need (3rd-party iframes, federated auth). |
Why this isn't a full defence
SameSite=Lax blocks the classic auto-submitting <form> attack from earlier — Chrome / Firefox / Safari all enforce it now. But:
- Older browsers / corporate-pinned versions don't enforce it.
- Subdomains can still bite you (
evil.yoursite.comis "same site"). - If your endpoint accepts GET for a state-changing action, Lax doesn't help (GET requests still send the cookie).
Use SameSite=Lax + a CSRF token together. Defence in depth.
What the form lesson says
The cookie attribute is a server concern, not HTML. But the form's method is yours: never use `method="get"` for anything that changes state. The whole SameSite + CSRF system assumes state changes happen via POST.
Sign up to start coding
Theory is open to everyone. The interactive editor, live preview, and check are unlocked with a 7-day free trial — card required, cancel anytime.
Sign up — free trial →First 10 lessons in each track are free. No card needed for those.