No. SameSite cookies remove a large share of CSRF attacks, but OWASP says the attribute does not replace a proper CSRF defence in most deployments. Keep it on, and add tokens or a custom header on state changing requests, plus a rule that GET never changes state.
Where SameSite helps
CSRF works because browsers attach cookies to requests that another site triggers. With SameSite=Lax or Strict, a hidden form on an attacker's page posting to your app no longer carries the session cookie, so the request arrives unauthenticated and fails.
Browsers now treat cookies without a SameSite attribute as Lax, which is why classic forged POST forms are far less effective than they used to be.
The gaps OWASP lists
The OWASP cheat sheet names four caveats worth remembering.
- Safe method navigations.
Laxstill sends cookies on top level navigations that use safe methods. If a GET endpoint deletes or changes something, a simple link can trigger it. - Same-site is not same-origin. The scope is the registrable domain. A vulnerable or taken over sibling subdomain counts as same-site and can send authenticated requests.
- Client side CSRF. SameSite does not protect against attacks that abuse client side code paths.
- Browser coverage. Older or non mainstream browsers may not enforce the attribute.
What to layer on top
Start with your framework. The cheat sheet's first advice is to use built-in CSRF protection if the framework has it.
If not, add a token to every state changing request and validate it on the server. Stateful apps can use a synchronizer token stored in the session. Stateless apps can use a signed double submit cookie, where the token is an HMAC bound to the session. The cheat sheet discourages the naive version that only compares a cookie to a request value, because an attacker who can write cookies can bypass it.
For API endpoints called from JavaScript, require a custom header such as X-CSRF-Token. Browsers send a preflight for cross-origin requests with custom headers, so a forged request from another origin is stopped unless your CORS policy allows that origin.
For very sensitive actions such as changing a password or email, ask the user to re-authenticate.
Fix the GET problem first
This is the cheapest improvement. Search your routes for GET handlers that write data, log out, delete or approve. Move them to POST, PUT, PATCH or DELETE. OWASP is blunt about it: do not use GET for state changing operations.
XSS undermines all of it
One more caveat. The OWASP page warns that cross-site scripting can defeat every CSRF mitigation, because script running in your origin can read tokens and send valid requests. CSRF defences assume you also fix XSS.
Quick check
Do I still need CSRF tokens if every cookie is SameSite=Strict?
OWASP still recommends adding at least one more control. Subdomain takeover, older browsers and client side CSRF are cases where SameSite alone leaves a hole.
Does a bearer token in an Authorization header need CSRF protection?
Browsers do not attach that header automatically, so the classic attack does not apply. The risk returns if the token is stored in a cookie.
Sources
Last reviewed: 19 October 2026.
