Technical
SameSite cookie
SameSite cookie is a cookie with the `SameSite` attribute set, which controls whether the browser sends it on requests that start from a different site. The values are `Strict`, `Lax`, and `None`.
How it is measured
Read the `Set-Cookie` header: `sid=...; SameSite=Lax; Secure; HttpOnly`. DevTools shows the value in the SameSite column under Application. Test cross-site by submitting a form from another origin to a login-protected POST and seeing whether the cookie arrives.
Chrome treats a missing attribute as Lax. `None` requires `Secure`, or the cookie is rejected and the console says so.
Worked example
An admin panel on `app.example` uses `SameSite=Lax`. A malicious page at `evil.example` auto-submits a POST to `/transfer`. The browser withholds the cookie on that cross-site POST, so the server sees an anonymous request and sends a 302 to login. With `None`, the cookie would travel and the transfer might go through.
An embedded widget on a partner site needs its cookie inside an iframe, so that one cookie is `SameSite=None; Secure` while the session cookie stays Lax.
How it differs
A SameSite cookie limits sending by the request's origin site. An HttpOnly cookie limits reading by script. SameSite blunts cross-site request forgery and HttpOnly blunts script theft. Neither covers the other's attack.
Common errors
Setting `None` without Secure. Using Strict on a login cookie and breaking links from email. Believing SameSite replaces CSRF tokens. Mixing up site and origin, since subdomains are the same site. Forgetting the cookie a third-party library sets. Expecting it to help against same-site XSS.
In practice
Set session cookies to Lax, use None only where a cross-site embed demands it, and keep a CSRF token on state-changing forms. Test the login flow by arriving from a link in an email.