Gera Tools

SameSite Cookie Attribute Reference

SameSite=None/Lax/Strict behavior with cross-origin request type matrix.

Reference for the SameSite cookie attribute values None, Lax and Strict, the Secure requirement for None, and whether a cookie is sent for each cross-site request type.

What is the default SameSite value?

Modern browsers treat a cookie with no SameSite attribute as Lax by default. Lax sends the cookie on same-site requests and on top-level cross-site navigations (like clicking a link) but not on cross-site subresource loads or background fetches.

The SameSite cookie attribute controls whether a cookie accompanies requests that originate from a different site, which is the core defence against cross-site request forgery (CSRF) and a key lever in third-party cookie deprecation. This reference covers the three values and shows, per request type, whether the cookie is sent.

How it works

The browser classifies each request as same-site or cross-site relative to the cookie’s domain, then applies the attribute:

Set-Cookie: session=abc; SameSite=Lax; Secure; HttpOnly
Set-Cookie: widget=xyz; SameSite=None; Secure

Strict sends the cookie only on same-site requests. Lax (the default) adds one exception — top-level cross-site navigations using a safe method, such as clicking a link. None sends the cookie on all cross-site requests but is rejected unless paired with Secure. Even None; Secure cookies are now frequently blocked as part of third-party cookie phase-out.

Tips and notes

  • Default to Lax; reserve Strict for the most sensitive session cookies.
  • SameSite=None without Secure is rejected — always pair them.
  • For embedded cross-site cookies, consider CHIPS (Partitioned) or the Storage Access API.
  • Lax still permits the cookie on top-level GET navigations, so it is not full CSRF immunity — also use CSRF tokens.
  • A subresource (image, script, fetch) to your own site from a third-party page is cross-site and follows these rules.