Website Security

SameSite Cookies: Lax, Strict and None Without Guesswork

SameSite controls cross-site cookie sending and helps reduce CSRF. Learn Lax, Strict, None and the Secure requirement.

Muhammad Azhar August 14, 2026 Reviewed August 14, 2026 3 min read

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.

Sources and further reading

Use the right privacy tool for the task

A browser proxy changes the network path for one session. Review the Privacy Policy and use a trusted direct connection for sensitive accounts.