Cybersecurity glossary
What is a SameSite Cookie?
Learn what the SameSite cookie attribute is, how Strict Lax and None change cross-site cookie sending, how SameSite helps with CSRF, and how to choose the right value.
Definition
SameSite is a cookie attribute that controls whether a browser includes a cookie on cross-site requests, with common values Strict, Lax, and None that trade CSRF resistance against cross-site functionality such as embeds and federated flows.
Why SameSite matters
Browsers attach cookies automatically. That convenience is exactly what classic CSRF exploits: a malicious page causes the browser to call your site while authenticated. The SameSite attribute gives servers a declarative way to limit when cookies travel with cross-site requests.
SameSite is now a default part of modern cookie security, but choosing the wrong value can break SSO, payments, or embedded admin tools—or leave CSRF gaps if set too permissively.
How SameSite works
On each request, the browser compares the site initiating the request with the site that owns the cookie, then applies the cookie’s SameSite policy.
Cookie is stored with SameSite
Set-Cookie declares Strict, Lax, or None (with Secure required for None).
A request is initiated
Navigation, fetch, form post, image, or iframe load starts from some site context.
Browser evaluates same-site vs cross-site
Registrable domain and scheme rules decide whether the request is cross-site.
Policy allows or withholds the cookie
Strict/Lax/None rules determine Cookie header inclusion.
Server sees authenticated or anonymous request
Missing cookies often appear as logged-out behavior on cross-site calls.
Values compared
| Value | Cross-site behavior | Typical use |
|---|---|---|
| Strict | Cookie withheld on all cross-site requests | High-sensitivity first-party sessions |
| Lax | Sent on top-level GET navigations; withheld on most cross-site subrequests | Default-friendly session cookies |
| None | Eligible for cross-site sending when Secure is set | Intentional cross-site embeds or federated flows |
Security and product trade-offs
CSRF reduction
Lax/Strict block many cookie-authenticated cross-site POSTs and silent subrequests.
Top-level login links
Lax still allows cookies on many click-through GET navigations from external sites.
Embed compatibility
None may be required for iframes and cross-site APIs that need credentials.
Privacy interaction
Even with None, third-party cookie restrictions may still block cross-site storage.
Choice checklist
- Start with SameSite=Lax for first-party session cookies unless you have a reason not to.
- Use Strict for especially sensitive apps when external inbound deep links with auth are unnecessary.
- Reserve SameSite=None; Secure for cookies that must work in deliberate cross-site contexts.
- Keep anti-CSRF tokens for defense in depth, especially on state-changing endpoints.
- Map OAuth, payment, and embedded admin flows before changing defaults.
- Set SameSite explicitly; do not rely on implicit browser defaults in documentation.
- Test schemeful same-site behavior across http/https and related subdomains.
- Remember that SameSite does not replace HttpOnly, Secure, or XSS prevention.
Pitfalls
SameSite=None without Secure is rejected. Multi-domain architectures (app.example vs auth.example) may be same-site or cross-site depending on eTLD+1 boundaries—get this wrong and sessions vanish. Also, Lax does not make every GET safe: state-changing GET endpoints remain a design smell regardless of cookies.
The practical takeaway
A SameSite cookie policy controls whether browsers attach that cookie to cross-site requests. Strict, Lax, and None balance CSRF defense against cross-site product needs.
Pick the tightest value your real user journeys allow, set it explicitly with Secure/HttpOnly as appropriate, and keep CSRF tokens for layered protection.
Related security terms
Cross-Site Request Forgery (CSRF)
Attack class SameSite is designed to reduce by limiting cross-site cookie sending.
Third-Party Cookie
Cross-site cookie usage that often requires SameSite=None when still allowed.
HttpOnly Cookie
Complementary attribute for script access control.
Fetch Metadata
Sec-Fetch-* request headers that can further constrain cross-site request handling.
Frequently asked questions
What is SameSite in simple terms?
SameSite tells the browser when a cookie may be sent if the request comes from another site. Stricter values reduce CSRF-style surprises; looser values enable some cross-site features.
What is the difference between Strict, Lax, and None?
Strict withholds the cookie on all cross-site requests. Lax allows it on top-level GET navigations but not on most cross-site subrequests. None allows cross-site sending and must be paired with Secure.
Does SameSite replace CSRF tokens?
Not completely. SameSite is strong mitigation for many cookie-based CSRF cases, but defense in depth with anti-CSRF tokens remains wise—especially for older browsers or complex site topologies.
Why did my OAuth popup break after SameSite changes?
Cross-site redirects and embedded login flows often need cookies available in cross-site contexts. Teams may need SameSite=None; Secure for specific cookies or a top-level redirect redesign.
What is the default SameSite if omitted?
Modern browsers commonly default omitted SameSite to Lax, but you should set the attribute explicitly for clarity and consistency.
Can SameSite=None work on HTTP?
No. Browsers require Secure when SameSite=None, which effectively requires HTTPS.
Is schemeful same-site important?
Yes. Browsers treat http and https as different sites in schemeful same-site models, which can surprise mixed-content or mixed-scheme deployments.
References
Explore authoritative guidance and frameworks related to samesite cookie.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.