It is reasonable to disable CSRF protection in Spring Security only for endpoints where a browser never attaches credentials automatically, such as a stateless API that expects an Authorization header you set in code. If any chain relies on session cookies or HTTP Basic prompts, keep CSRF on.
The one question that decides it
CSRF works because browsers automatically attach cookies and some other credentials to requests, even ones started by another site. So ask: does the browser send credentials to this endpoint without your own code adding them?
| How the endpoint authenticates | Browser attaches it automatically? | CSRF protection |
|---|---|---|
| Session cookie (form login) | Yes | Keep on |
| HTTP Basic through a browser prompt | Yes | Keep on |
| Bearer token in an Authorization header set by your code | No | Often off for that chain |
| Mutual TLS client certificate | Yes, at the connection | Think carefully |
| Machine to machine calls, no browser | No | Often off for that chain |
This table is guidance from the mechanism, not a rule from the framework. The Spring Security reference shows how to disable the feature with csrf((csrf) -> csrf.disable()) and leaves the decision to you.
Split chains instead of turning it off globally
Spring Security lets you define more than one SecurityFilterChain. Put the stateless API under its own chain and leave the browser facing chain with defaults. A global disable written for one API quietly removes protection from the admin console next to it.
Steps
- List every route and how it authenticates.
- Group routes into browser session routes and token only routes.
- Create one chain per group, using a request matcher to select routes.
- Disable CSRF only on the token only chain.
- Make the token only chain truly stateless. If it can also accept a session cookie, the reasoning no longer holds.
- Add a test that confirms a cookie alone cannot authenticate the API chain.
Traps that break the reasoning
- Accepting both a cookie and a bearer token on the same route.
- Storing a token in a cookie that the browser sends automatically.
- Leaving H2 console or other dev tools on a chain where protection is off.
- Copying a "disable CSRF" snippet from a tutorial without knowing which chain it applies to.
Cross origin rules are a separate matter. CORS does not stop CSRF, as we explain in does CORS stop CSRF.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is disabling CSRF fine for any REST API?
No. It depends on how the API authenticates. If it uses session cookies, a browser sends them automatically and protection should stay on.
Is SameSite enough instead?
It helps but is not a full substitute everywhere. See our post on whether SameSite is enough.
Sources
Last reviewed: 19 October 2026.
