SameSite cookie modes

Slap yourself if

You think SameSite is just a CSRF toggle or assume SameSite=None is harmless if you add Secure.

Why this exists

Because SameSite defaults silently broke authentication flows, third-party embeds, and OAuth integrations — and many teams still don’t understand why.

Mental model

SameSite is a request-context filter. The browser decides whether cookies are attached based on navigation type, request initiator, and site boundaries — not developer intent.

  • The browser classifies a request as same-site or cross-site.
  • SameSite rules are evaluated before the request is sent.
  • Cookies may be silently excluded without server involvement.
  • Different navigation types trigger different SameSite behavior.
  • Breaking OAuth or SSO redirects with SameSite=Lax.
  • Using SameSite=None without Secure and losing cookies entirely.
  • Assuming fetch and navigation behave the same.
  • Debugging server-side auth when the cookie was never sent.

SameSite controls whether cookies are attached to cross-site requests based on request context, with Lax, Strict, and None enforcing progressively weaker restrictions.

  • Calls it a CSRF fix.
  • Ignores navigation vs fetch differences.
  • Assumes cookies always reach the server.
  • Does not mention default changes.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

How browsers decide what 'same-site' means

Strict vs Lax vs None: what actually gets sent

Why authentication flows break silently

Why SameSite is a browser-enforced security boundary

How SameSite explanations expose shallow security thinking