Yes. Spring Security protects against cross site request forgery by default for unsafe HTTP methods such as POST, so a basic setup needs no extra code. The expected token is stored in the HTTP session unless you change the repository. If CSRF has been disabled somewhere in your config, none of this applies.
What "on by default" means
CSRF (cross site request forgery) is an attack where a malicious page makes a logged in user's browser send a state changing request to your application. The defence is a secret token that the attacker's page cannot read, which your server requires on requests that change state.
The Spring Security reference states that it protects against CSRF attacks by default for unsafe HTTP methods, and that you can write the default explicitly with csrf(Customizer.withDefaults()). It also says login requests are protected, so an attacker cannot forge a login against your users.
Where the token lives
| Piece | Default behaviour |
|---|---|
| Repository | HttpSessionCsrfTokenRepository, which keeps the expected token in the session |
| Loading | Deferred, so the session is not loaded on every request (Spring Security 6) |
| Per request value | Includes randomness to resist a BREACH style attack (Spring Security 6) |
| Alternative | CookieCsrfTokenRepository stores the token in a cookie |
Server rendered pages that use Thymeleaf or similar templates usually pick up the token automatically in forms. Anything that submits requests with JavaScript has to send the token itself, usually in a header.
Steps to confirm it is working
- Search your configuration for
csrfanddisable. A disable call in a shared security config is the most common reason protection is missing. - Check every
SecurityFilterChainbean. Each chain has its own CSRF setting, and a second chain for an API may legitimately differ from the first. - Send a POST without a token to a protected endpoint from a test. It should be rejected with a 403.
- Review logout. With CSRF on, the logout filter only handles POST requests.
- Make sure your front end sends the token on every unsafe request, including file uploads.
What it does not cover
CSRF protection is one control. It does not replace authentication, authorization checks or input validation. It also does not help requests that never use browser managed credentials. If your API uses bearer tokens held in JavaScript, the risk model is different, which is covered in our post on CSRF protection for JSON APIs.
A dependency scanner will not see a disabled CSRF setting, because it is a configuration choice rather than a vulnerable component. Review it in code review. Our CSRF code review checklist lists what to look for.
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
Does Spring Security check GET requests for a CSRF token?
No. The default protection applies to unsafe methods such as POST. This is why GET handlers must never change state.
Do I need to add the CSRF configuration myself?
Not for the default behaviour. The explicit call is only needed when you want to customise it, for example to change the token repository.
Sources
Last reviewed: 19 October 2026.
