flawopen.com/CSRF/SameSite cookies
Does SameSite=Strict replace CSRF tokens?
SameSite=Strict is a strong browser-enforced layer for cookie-authenticated requests that originate from another site, but it is not a universal CSRF defense. Same-site sibling subdomains are still considered same-site even when they are different origins, and clients that do not enforce the attribute get no protection. Keep a CSRF token or another request-origin defense where the threat model requires it.
What SameSite actually does
A SameSite=Strict cookie is withheld on cross-site requests, including the classic CSRF pattern where another site submits a form to your application. This blocks the browser's automatic attachment of that session cookie in that context. SameSite is scoped to a site, not an origin: requests from a sibling subdomain may still be same-site, so Strict does not protect against a compromised or untrusted sibling host. Strict can also leave a user unauthenticated after following an external link because the cookie is withheld on that navigation.
Where it still falls short
If authentication uses a bearer token that the application explicitly places in an Authorization header, SameSite does not control that header. The browser's automatic cookie behavior is different. This does not make every such design safe: assess whether the browser can attach credentials automatically through another mechanism, and protect tokens against theft and misuse.
Explicit SameSite=Lax permits same-site requests and cross-site top-level navigations using a safe method such as GET; it withholds the cookie on cross-site subrequests and unsafe-method navigations. An omitted attribute uses the user agent’s default. In Chromium, that default differs from explicit Lax: the current implementation allows some cookies without an explicit attribute on top-level cross-site unsafe requests for up to 2 minutes after creation (Lax-allowing-unsafe). Do not rely on this browser-specific compatibility behavior for CSRF. Set the intended attribute explicitly, test supported clients, and never make state-changing operations reachable through a safe method.
SameSite enforcement is a browser behavior. A client that does not support or honor the attribute provides no protection from it. Check the clients your application supports, and treat SameSite as defense in depth alongside an appropriate CSRF token, Origin validation, or another primary defense.
FAQ
See the dedicated guidance on safe methods. Do not make any state-changing action reachable through a safe method such as GET; safe methods are expected not to change server state.