SameSite Cookies

The `SameSite` cookie attribute controls whether a browser includes a cookie when a request crosses site boundaries. It is primarily a browser-side defense against cross-site request forgery (CSRF), with `Lax`, `Strict`, and `None` providing different levels of cross-site cookie sending.

A cookie's `SameSite` setting determines whether the browser sends that cookie with requests initiated from another site. This decision is made by the browser, so frontend JavaScript cannot override a cookie's `SameSite` policy.

`Strict` is the most restrictive setting: the cookie is generally withheld on cross-site requests. `Lax` allows cookies in same-site contexts and in certain top-level navigations to the cookie's site, making it a common default for session cookies. `None` permits the cookie to be sent in cross-site contexts, but it must also use the `Secure` attribute.

The distinction is about sites, not simply different origins. A cross-origin request can still be same-site, while a request between different sites can be cross-site. Modern cookie site calculations account for the scheme, so `http` and `https` can matter.

SameSite is useful for reducing CSRF exposure, but it is not a complete authentication or authorization mechanism. Applications should still validate state-changing requests appropriately, especially when legitimate cross-site integrations require cookies.

A frontend developer usually encounters the setting when inspecting `Set-Cookie` response headers or configuring cookies through a backend framework. `document.cookie` cannot set `HttpOnly`, and cookies marked `HttpOnly` remain inaccessible to client-side JavaScript even though the browser can attach them to eligible requests.

Key points

• `Strict` restricts cookies most strongly in cross-site situations.
• `Lax` permits same-site requests and selected top-level cross-site navigations.
• `None` allows cross-site cookie sending and requires `Secure`.
• SameSite is evaluated by the browser and cannot be bypassed with frontend JavaScript.
• SameSite helps mitigate CSRF but should not be treated as the only CSRF defense.

Interview questions

What does the SameSite cookie attribute do?

`SameSite` tells the browser when a cookie may be included in requests involving a different site. `Strict` is restrictive, `Lax` permits some cross-site top-level navigations, and `None` permits cross-site use. `None` requires `Secure`. The attribute is commonly used to reduce CSRF risk.

What is the difference between SameSite=Lax and SameSite=Strict?

`Strict` applies the strongest restriction and generally prevents the cookie from being sent in cross-site contexts. `Lax` is more permissive and allows the cookie for certain top-level navigations to the cookie's site. This can make `Lax` more practical for ordinary login sessions where users may follow links from other sites. Neither setting means the cookie is universally available to every request.

Why does SameSite=None require Secure?

`SameSite=None` explicitly permits a cookie to be used in cross-site contexts. Requiring `Secure` ensures that such a cookie is transmitted only over HTTPS. This prevents a configuration intended for cross-site use from also permitting transmission over an unencrypted HTTP connection. The two attributes therefore address different security properties.

Does SameSite completely prevent CSRF?

No. SameSite substantially reduces some cross-site cookie-based request scenarios, but an application should not rely on it as its only CSRF defense. The appropriate protection also depends on the application's request patterns and whether cross-site requests are intentionally supported. State-changing operations should have suitable server-side validation and, where appropriate, CSRF tokens or origin checks.

How is SameSite different from CORS?

SameSite controls whether cookies are attached to requests based on the site's relationship to the request context. CORS controls whether browser JavaScript from one origin is allowed to read a response from another origin. A request can therefore be affected by both mechanisms independently. Allowing an origin through CORS does not automatically make a cookie eligible for cross-site transmission.