Skip to content

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 Editorial date: November 7, 2026 2 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, appropriate Path values and a host-only Domain scope where possible, and rotate sessions after authentication.

“Site” is not the same as “origin”

Modern SameSite uses the scheme and registrable domain; origin additionally distinguishes host 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.

Use SameSite with server-side controls

Explicit Lax normally allows cross-site cookies only on top-level navigations using safe methods. A cross-site POST callback can therefore need a different design. SameSite=None permits cross-site use but does not override browser third-party-cookie restrictions.

Use SameSite as one CSRF layer. Sensitive state changes still need method discipline and appropriate origin validation or anti-CSRF tokens. Prefer a host-only cookie when cross-subdomain use is unnecessary. Path controls delivery, not an isolation boundary against other code on the host.

Use the shortest practical session lifetime, rotate identifiers after authentication and invalidate sessions on logout or account recovery. Inspect the public Set-Cookie response because reverse proxies and legacy middleware can rewrite attributes. Record why each cross-site cookie is needed and test forged submissions and authentication callbacks.

Sources and further reading