The SameSite attribute controls when a browser includes a cookie in cross-site requests. It is an important CSRF defence but can also break legitimate sign-in and payment returns if chosen blindly.
The three values
- Strict: strongest cross-site restriction, with possible usability cost.
- Lax: practical default for many session cookies.
- None: allows cross-site use and requires
Secure.
Test real flows
Check OAuth callbacks, payment providers, embedded applications and emailed links. Record which cookies require cross-site behavior rather than setting every cookie to None.
Use the full cookie baseline
Add Secure, HttpOnly where scripts do not need access, narrow Path and Domain values, and rotate sessions after authentication.
“Site” is not the same as “origin”
SameSite uses registrable-domain concepts, while origins also include scheme and port. Developers should test subdomains and scheme changes rather than assuming ordinary same-origin intuition applies.
Legacy clients
If an application supports old embedded browsers, verify how they interpret SameSite=None. Compatibility work should be isolated; weakening every session cookie for old clients creates a larger risk.
Select behavior from the actual user journey
Strict suits cookies that never need cross-site entry, but it can interrupt legitimate navigation. Lax supports many top-level navigation flows and is a common session default. None is required for genuine cross-site embedding and must be paired with Secure in modern browsers.
Test more than the happy path
Check external identity sign-in, payment returns, emailed links, embedded widgets, subdomains and scheme changes. SameSite is based on “site” concepts, which are not identical to origin. Older embedded browsers may also interpret None differently.
Use SameSite as one CSRF layer, not the only one. Sensitive state changes still need method discipline, origin checks or anti-CSRF tokens, and every session cookie should be scoped as narrowly as the application permits.
Inspect the Set-Cookie response in browser developer tools instead of assuming a framework default. Record the reason for every cross-site cookie so a future developer does not weaken the whole application to fix one integration.
Classify why each cookie crosses sites
SameSite=Lax is a sensible starting point for many login sessions because it limits common cross-site requests while allowing top-level navigation in normal cases. Strict is tighter but may interrupt legitimate inbound journeys. None permits cross-site use and must be paired with Secure.
Do not set one global value without mapping sign-in redirects, payment providers, embedded widgets and API clients. Test with the browsers and flows your users actually have. A cookie that disappears during an OAuth callback often looks like a random authentication failure.
Combine attributes with server-side checks
Use HttpOnly for session cookies, Secure over HTTPS, a narrow path and the shortest practical lifetime. Avoid a broad domain attribute when a host-only cookie is enough. Rotate identifiers after authentication and invalidate them on logout or account recovery.
SameSite reduces some CSRF exposure but does not replace anti-CSRF tokens, origin validation or authorization. Write integration tests for cross-site form submissions and authentication callbacks so browser policy changes do not silently weaken or break the application.
Inspect the public response to confirm the final attributes. Reverse proxies and legacy middleware can rewrite or duplicate cookie headers even when the framework configuration appears correct.