SameSite cookies: what they are and how to set them

Cookies are key-value pairs with attributes that decide when and where the browser sends them. The SameSite attribute, defined in RFC6265bis, lets you state whether a cookie belongs in a first-party or same-site context. Understanding what "site" means here matters: a site is the domain suffix plus the part of the domain just before it. www.web.dev and static.web.dev, for instance, both belong to the web.dev site.

Some domain registries use the public suffix list to define site boundaries beyond simple top-level domains. Services like github.io appear on that list, so your-project.github.io and my-project.github.io are treated as separate sites. A request from one to the other is a cross-site request.

The attribute offers three values: Strict, Lax, and None. Leaving it off entirely is also an option, though not recommended.

SameSite=Strict restricts the cookie to first-party contexts only: the cookie's site must match the site in the address bar. A cookie like promo_shown set with this value would not be sent on the initial request when a user arrives via a link from another site. That behavior suits features that sit behind an initial navigation, such as password changes or purchases, but it is too limiting for cookies that store display preferences.

SameSite=Lax relaxes that restriction for top-level navigations. If another site links to your content directly, the browser will include the cookie on that request even though the navigation started elsewhere. For example, with a Lax cookie, a request for an image embedded from your site would not include the cookie, but clicking a link to a page on your site would. This is the recommended setting for cookies that affect how your site displays, while cookies tied to user actions should use Strict.

SameSite=None signals that a cookie should be sent in all contexts. Services that other sites consume—widgets, embedded content, affiliate programs, advertising, or cross-site sign-in—should use None to make that intent explicit.

What happens when SameSite is absent

Despite wide support for the attribute, adoption has lagged. Cookies set without SameSite have historically defaulted to being sent in all contexts, exposing users to CSRF attacks and unintentional information leakage. The IETF proposal Incrementally Better Cookies addresses this with two changes:

  • Cookies without a SameSite attribute are treated as SameSite=Lax.
  • Cookies with SameSite=None must also specify Secure, requiring a secure context.

Both changes remain compatible with browsers that implement the earlier version of SameSite and with those that do not support it at all. The goal is to force developers to state their intentions rather than rely on browser defaults. Clients that do not recognize SameSite=None should ignore it.

Defaulting to Lax

If a cookie is sent without a SameSite attribute, the browser treats it as SameSite=Lax. Even so, explicitly setting SameSite=Lax is still recommended for consistent behavior across browsers.

Requiring Secure for None

Cross-site cookies declared with SameSite=None must also include the Secure attribute or the browser will reject them. You can test this in Chrome 76 by enabling about://flags/#cookies-without-same-site-must-be-secure, and in Firefox 69 by setting network.cookie.sameSite.noneRequiresSecure in about:config.

Existing cookies should be updated to Secure as soon as possible. If you depend on third-party content providers, verify that their cookies comply and update any snippets or dependencies on your own site to use the new behavior.

For detailed guidance on migrating cookies and handling the subtle browser differences, see the companion article on SameSite cookie recipes.