SameSite cookie

What it means

SameSite is an attribute on a cookie that controls whether the browser sends it along with requests that start on a different site. It has three values. Strict never sends it cross-site. Lax sends it only on top-level navigations that use safe methods such as GET. None sends it everywhere, and must be paired with Secure.

Its main purpose is to blunt cross-site request forgery. If the session cookie is not sent when another site triggers a form post, the forged request arrives without a session and fails. It is a cheap, useful default, set in one header.

Why it matters

It closes a whole family of attacks with one attribute, and costs nothing if set early. It also protects some cross-site data leaks. Left unset, an app depends on whatever the visitor's browser decides, and that differs between browsers and versions.

It is not a complete answer. A site is not an origin: subdomains of the same registrable domain count as the same site, so a flaw on any one of them can still send authenticated requests. OWASP treats SameSite as defence in depth alongside CSRF tokens.

How it shows up

Most frameworks set SameSite on the session cookie for you, often to Lax. Chromium-based browsers treat a cookie without the attribute as Lax, but other browsers differ, so set it explicitly. Use Strict for cookies that guard high-value actions, and None only when a cookie truly must travel cross-site, for example in an embedded widget.

The mistakes: None used to "fix" a login redirect without understanding why, then left in place; Lax assumed to cover state changes made with GET; and a long-lived cookie shared with a loosely maintained subdomain. Check each cookie's attributes in the response headers, and remember cookie scope matters too.