The SameSite Cookie Attribute: Lax, Strict and None

The SameSite attribute controls whether a cookie is attached to requests that come from other sites. It is the primary defence against cross-site request forgery (CSRF). Set it explicitly to Lax (a sensible default) or Strict on your cookies. A missing SameSite is only a minor gap today, because modern browsers already default to Lax — but None without Secure is a real error.

For the site owner (plain English)

In plain terms, SameSite controls whether your cookie tags along when a request comes from another website — the mechanism behind a class of trick called cross-site request forgery. Here is the reassuring part: if a checker says your SameSite is simply missing, that is a minor housekeeping note, not an emergency. Modern browsers already apply a safe default on your behalf, so you are largely covered even without setting it. It is still tidier to set it explicitly, and the simplest path is to ask your developer to set it toLax. The one thing that genuinely needs attention is the combinationNone without Secure, which browsers reject outright — but that is a specific misconfiguration, not the everyday “missing” case.

The three values

• Strict — the cookie is never sent on any cross-site request, including when a user clicks a link from another site into yours. Strongest CSRF protection, but it can log users out when they follow an inbound link, so it suits sensitive apps (banking, admin).
• Lax — the cookie is sent on top-level navigations (clicking a link) but not on cross-site sub-requests like images, iframes, or background fetch/form POSTs. This blocks the classic CSRF attack while keeping normal inbound links working. It is the right default for most session cookies.
• None — the cookie is sent on all cross-site requests. Required for genuine cross-site use (embedded widgets, some SSO and payment flows), and the browser mandates Secure alongside it.

Why a missing SameSite is only a minor gap

Years ago, a cookie with no SameSite attribute was sent on every cross-site request, which left it open to CSRF. That changed: since 2020, Chrome and the other major browsers treat a cookie with no SameSite as SameSite=Lax by default. So an absent attribute now inherits the same protection as an explicit Lax for the common cases.

SameSite=None must be paired with Secure

The one genuine error in this area is SameSite=None without Secure. Browsers refuse to store a cross-site cookie that isn't marked Secure, so the cookie is silently dropped and whatever depended on it quietly breaks. If you truly need a cross-site cookie, always write both together:

Set-Cookie: sid=<token>; SameSite=None; Secure; HttpOnly; Path=/

And before reaching for None, ask whether you really need cross-site sending — most session cookies don't, and Lax is both safer and simpler.

How to set SameSite

# Raw header — the recommended default for a session cookie
Set-Cookie: sid=<token>; SameSite=Lax; Secure; HttpOnly; Path=/

// Express
res.cookie("sid", token, { sameSite: "lax", secure: true, httpOnly: true });

# Django settings.py
SESSION_COOKIE_SAMESITE = "Lax"
CSRF_COOKIE_SAMESITE = "Lax"

# Rails
Rails.application.config.session_store :cookie_store, key: "_app_session", same_site: :lax

// PHP
setcookie("sid", $token, ["samesite" => "Lax", "secure" => true, "httponly" => true]);

SameSite is a strong layer, but it is not a complete CSRF solution by itself — keep your anti-CSRF tokens for state-changing requests, especially if you must support SameSite=None anywhere. SameSite reduces the attack surface; tokens close the remaining gap.

See the cookie security guide for the full picture, and pair this with Secure and HttpOnly.