SameSite is a cookie attribute that controls when browsers send cookies with cross-site requests.
Backend developers usually run into SameSite when building login flows, session cookies, embedded apps, OAuth redirects, or CSRF defenses.
Quick answer
SameSite helps reduce CSRF risk by limiting when cookies are automatically attached to cross-site requests.
The common values are:
SameSite=Strict: send the cookie only for same-site requests.SameSite=Lax: send the cookie for same-site requests and some top-level navigations.SameSite=None: send the cookie in cross-site contexts, but only when the cookie is alsoSecure.
For many traditional web apps, SameSite=Lax is a practical default for session cookies. For embedded cross-site apps, third-party integrations, or some OAuth patterns, you may need SameSite=None; Secure plus stronger CSRF and origin checks.
Site vs origin
SameSite is about sites, not just origins.
An origin includes scheme, host, and port:
https://app.example.comA site is based on the registrable domain and scheme. For example, https://app.example.com and https://api.example.com are usually same-site, even though they are different origins.
This distinction matters because CORS is about cross-origin browser reads, while SameSite is about when cookies are sent on cross-site requests.
Do not treat SameSite and CORS as interchangeable controls.
SameSite cookie modes
| Mode | Cookie sent on same-site requests? | Cookie sent on most cross-site subrequests? | Common use |
|---|---|---|---|
Strict | Yes | No | Sensitive apps where cross-site navigation should not carry login state |
Lax | Yes | Usually no, except some top-level navigations | Default session cookie choice for many web apps |
None | Yes | Yes, when Secure is also set | Embedded apps, third-party contexts, some cross-site integrations |
Strict provides stronger CSRF reduction, but it can surprise users who follow links from email, docs, or external systems and appear logged out for the first navigation.
Lax is a balanced default for many applications.
None is necessary when cookies must work in cross-site contexts, but it increases the need for other defenses.
How SameSite reduces CSRF
CSRF depends on the browser automatically attaching credentials to a request the user did not intend.
Cookie-based sessions are convenient because the browser sends the cookie automatically. That same convenience creates CSRF risk for state-changing endpoints.
SameSite can block many cross-site requests from carrying session cookies. If the cookie is not sent, the backend sees an unauthenticated request.
That said, SameSite is not a complete CSRF strategy. You should still design sensitive endpoints with CSRF tokens, origin checks, appropriate HTTP methods, and clear authorization checks.
Read CSRF vs XSS for the broader threat model.
OAuth and login redirects
Authentication flows can make SameSite choices tricky.
OAuth and OpenID Connect flows often involve redirects between your app and an identity provider. If your login flow depends on cookies during the redirect callback, overly strict cookie settings may break the flow.
For example, a backend may store a temporary state value in a cookie before redirecting the user to the identity provider. When the identity provider redirects back, the backend must compare the returned state value.
If the cookie is not sent on the callback request, the login may fail.
This does not mean every auth cookie needs SameSite=None. It means you should test the exact login flow, callback route, browser behavior, and cookie attributes together.
Read OAuth 2.0 vs OpenID Connect for the difference between delegated authorization and login.
Secure cookie checklist
For session cookies, a common starting point looks like this:
Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/Useful cookie attributes:
HttpOnlyprevents JavaScript from reading the cookie directly.Securesends the cookie only over HTTPS.SameSitecontrols cross-site sending behavior.Pathnarrows where the cookie is sent.Max-AgeorExpirescontrols lifetime.
Cookie flags do not replace backend authorization. They reduce browser-side risk around credential handling.
Common mistakes
The first mistake is assuming SameSite=Lax fixes all CSRF. It reduces risk, but state-changing endpoints still need deliberate protections.
The second mistake is using SameSite=None without understanding why. If a cookie is sent cross-site, the backend must be stricter about CSRF and origin behavior.
The third mistake is confusing same-site with same-origin. Subdomains can be same-site but cross-origin, which changes how cookies and CORS behave.
The fourth mistake is storing bearer tokens in JavaScript-accessible storage to avoid cookie complexity. That can reduce classic CSRF risk but may increase XSS impact.
The fifth mistake is changing cookie settings without testing login, logout, OAuth callback, iframe, mobile webview, and cross-subdomain behavior.
Practical recommendation
For a normal web application using server-side sessions, start with:
HttpOnly; Secure; SameSite=LaxThen test the login and logout flows, state-changing forms, API calls, and OAuth callbacks.
Use SameSite=Strict for highly sensitive areas if user experience allows it. Use SameSite=None; Secure only when cross-site cookie behavior is genuinely required, and pair it with CSRF tokens, origin checks, and careful endpoint design.
SameSite is a useful browser defense. It is not a complete authorization model.
Related reading
Read Cookie Security Checklist for a launch-ready cookie review and Cookie vs Token Authentication for the broader credential tradeoff. Read CSRF vs XSS for the difference between request forgery and script injection.
Read CORS Explained for Backend Developers, CORS Preflight Explained, and Secure HTTP Headers Explained before mixing SameSite and cross-origin API calls. For auth architecture tradeoffs, read JWT vs Session Authentication, Session Fixation Explained, and Access Token vs Refresh Token. For the full sequence, browse the Authentication Learning Path, Backend Security Learning Path, and Topics.