How the SameSite cookie attribute works

The SameSite attribute tells a browser when it may include a cookie in a cross-site request. This reduces some privacy leaks and helps protect against cross-site request forgery (CSRF).

When this article was written, Chrome, Firefox, and other browsers were moving towards the secure-by-default behaviour described in the IETF proposal Incrementally Better Cookies. Cookies without a declared value would be treated as SameSite=Lax. Cross-site cookies needed SameSite=None; Secure.

That mattered to authentication systems, advertisers, publishers, and anything else relying on third-party cookies. A cookie that previously worked without an attribute could stop being sent.

The Chrome 80 change

Chrome 80 introduced this default in February 2020. Sites that intentionally used cookies across origins had to mark them explicitly.

Choose the narrowest option that works

For a cookie used only on your own site, choose SameSite=Lax or SameSite=Strict, depending on the flow. Being explicit avoids relying on defaults that have changed over time.

For a cookie genuinely needed in a third-party context, use both attributes:

Set-Cookie: session=value; SameSite=None; Secure

Without Secure, the browser rejects a cookie marked SameSite=None.

What the three values mean

Strict sends the cookie only in a first-party context. It can suit sensitive cookies, but may also interrupt an expected flow when someone arrives through an external link.

Lax allows the cookie in the first-party context and in some top-level navigations, such as following a normal link. It withholds the cookie from many cross-site subrequests, including images and frames.

None allows the cookie in both first-party and cross-site requests. It is not a more compatible version of Lax; it deliberately permits more requests and requires HTTPS.

For most cookies, I would start with Lax, consider Strict for sensitive first-party behaviour, and use None; Secure only when the feature actually crosses site boundaries.