SameSite Cookies
SameSite controls whether cookies are sent on cross-site requests. Lax, Strict, and None have different CSRF and usability trade-offs, and None requires Secure.
Definition
SameSite is a cookie attribute that tells the browser whether to attach the cookie when a request originates from another site. Strict sends the cookie only on same-site requests; Lax sends it on same-site requests and top-level safe navigations such as clicking a link; None sends it on all requests and requires the Secure attribute. The browser's site definition is based on registrable domain, not full origin.
Context and scope
SameSite is a primary defense against CSRF and a privacy control for cross-site tracking. It also affects login flows, embedded widgets, and payment redirects: a cookie needed after a cross-site redirect may be missing under Strict or Lax. Choose the strictest setting that supports the product's cross-site journeys.
Common misconceptions
- SameSite replaces CSRF tokens — it reduces risk but does not cover all clients, subdomain attacks, or legacy browsers
- Lax blocks all cross-site requests — top-level GET navigations still send Lax cookies
- None is the safe default — None disables the cross-site restriction and requires Secure; use it only when embedding genuinely requires it
Anti-patterns
- Setting SameSite=None without Secure
- Using SameSite=Strict for a cookie needed after an OAuth or payment redirect
- Assuming localhost and production share the same site semantics
Related concepts
Related examples
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
The three modes
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax; Path=/- Strict — not sent on any cross-site request. Strongest CSRF protection, but a user arriving from an external link appears signed out on the first navigation.
- Lax — sent on same-site requests and top-level safe navigations. A practical default for session cookies.
- None — sent on all requests; required for some embedded or cross-site contexts, and must be paired with
Secure.
Why it matters
CSRF relies on the browser attaching cookies to a cross-site request. SameSite prevents that attachment for most state-changing cross-site requests, but it is not a complete CSRF defense: subdomains and same-site attackers may still qualify, and some clients may not enforce the attribute.
When to use which
Use Lax for ordinary session cookies. Use Strict for sensitive cookies that should never accompany a cross-site navigation, such as an admin session on an internal tool. Use None only for legitimate cross-site embedding, with Secure and a clear review of the risk.
Pitfalls
A cookie set without SameSite may be treated as Lax by modern browsers but differently by older ones; set it explicitly. None without Secure is rejected. OAuth and payment redirects are the most common places where Strict breaks a legitimate flow; test the full redirect chain, not only a direct request.