how to set SameSite cookies correctly

TL;DR

SameSite controls when the browser attaches a cookie to cross-site requests: Lax (the modern default) sends it on top-level navigations but not on cross-site subrequests, which kills most CSRF; Strict never sends it cross-site, which is safest but logs users out when they arrive from external links; None allows cross-site sending but requires the Secure flag and HTTPS. For login/session cookies, Lax is the right default; reach for Strict only where the UX cost is acceptable.

how to set SameSite cookies correctly

Use this when

• You are setting a session, auth, or CSRF cookie and need to pick a SameSite value
• A CSRF review asks what protects your cookie-based endpoints
• An embedded widget, iframe, or cross-site API flow stopped receiving cookies
• You are debugging 'cookie not sent' after a browser update

Not for

• GDPR cookie-consent banners (legal question, not this attribute)
• Deciding between cookies and bearer tokens overall
• Same-origin cookie flags like HttpOnly (related but separate)

Steps

1. Default to Lax for session cookies. Set it explicitly rather than relying on browser defaults: Set-Cookie: session=[id]; Path=/; HttpOnly; Secure; SameSite=Lax. Lax blocks the dangerous case (a malicious site triggering a state-changing POST with your cookie) while letting normal link clicks into your site keep the user logged in.

Expected output: the Set-Cookie response header shows SameSite=Lax, and cross-site POSTs from a test page arrive without the cookie.

1. Use Strict where the UX tradeoff is worth it. Banking, admin panels, and settings pages benefit from Strict because the cookie never leaves your site context. Warn users (or handle gracefully) that arriving via an external link starts logged out until they navigate inside the site.

Expected output: clicking a link from email to the admin panel shows a logged-out state until the user clicks any in-site link.

1. Use None only for genuinely cross-site needs, and always with Secure. Embedded checkouts, widgets, or SSO flows that must work inside third-party iframes need SameSite=None; Secure (HTTPS only). Browsers reject SameSite=None without Secure outright.

Expected output: the iframe flow receives its cookies, and the Set-Cookie header shows both SameSite=None and Secure.

1. Keep HttpOnly and Secure alongside SameSite. SameSite stops cross-site sending; HttpOnly stops JavaScript from reading the cookie (XSS defense); Secure stops it leaking over plain HTTP. They are three independent layers, and session cookies normally want all three.

Expected output: document.cookie in devtools does not reveal the session cookie, and it is never sent over http.

1. Test the matrix in a real browser. Build a tiny test page on a different origin that issues GET, top-level navigation, and POST requests to your app, and watch which requests carry the cookie in devtools. Also test your OAuth/OIDC callback flow, which is a cross-site POST in some providers and breaks under Strict.

Expected output: a table of request types vs cookie presence that matches your intent, with the OAuth callback verified working.

1. Watch for the Lax-by-default gotcha on older setups. If you never set SameSite, modern browsers treat it as Lax, which can silently break old cross-site integrations that assumed cookies always flow. Set the attribute explicitly everywhere so behavior is intentional.

Expected output: no cookie in your app relies on an unset SameSite attribute.

Variant phrasings

• "SameSite Lax Strict None explained"
• "Set-Cookie SameSite example"
• "why is my cookie not sent in iframe"
• "SameSite None Secure not working"

Edge cases and pitfalls

• Some OAuth providers POST the callback cross-site; Strict on the session cookie can break login, so test the full login round-trip after changing it.
• iOS Safari versions have had quirky SameSite=None handling; if you must support older Safari in iframes, test there specifically.
• SameSite is a mitigation, not a full CSRF fix: keep anti-CSRF tokens on state-changing endpoints too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aMflpk0MXnYzw6ohybp7Ag