CSRF Cross-Site Request Forgery – Java Backend Security
Fast recall
Quick revision
Core answer
Authorization header, because the browser does not attach that header automatically. A cross-site form therefore has no credential to reuse. If the same JWT is stored in an automatically sent cookie, or another ambient credential can authenticate the endpoint, CSRF protection is still needed.Interview-ready guide
Interview answer
A stateless API is not protected from CSRF merely because its token is a JWT. The usual protection comes from sending the token as a bearer value in the Authorization header. The browser does not add that header automatically, so a cross-site form reaches the API without a credential and the API rejects it.
A script on another origin also needs the token and must pass a CORS preflight before the browser can send an Authorization header. The server should allow only trusted origins. The core point, however, is that there is no ambient credential for the attacker to reuse.
If the JWT is stored in a cookie that authenticates the request, the browser may send it automatically and CSRF is possible again. The same applies if the endpoint also accepts a session cookie, HTTP Basic authentication, or a client certificate. CSRF can be disabled for a Spring Security chain only after confirming that its accepted credentials are supplied explicitly rather than automatically.
CSRF Cross-Site Request Forgery – Java Backend Security
Direct Answer
A JWT does not prevent CSRF by itself. A browser API is normally outside the usual CSRF threat when its only credential is a bearer token that client code adds to the Authorization header, because the browser does not attach that header automatically. A cross-site form therefore has no credential to reuse. If the same JWT is stored in an automatically sent cookie, or another ambient credential can authenticate the endpoint, CSRF protection is still needed.
Common Mistakes & Pitfalls
- Treating JWT as a CSRF feature: a JWT in a cookie is still an automatically sent credential.
- Ignoring another authentication path: a bearer API that also accepts a session cookie may still be exposed.
- Calling header requests impossible cross-origin: an
Authorizationheader triggers preflight; the server's CORS policy decides whether the browser may continue. - Using local storage as a complete security fix: it avoids automatic cookie sending but makes token theft through XSS a separate concern.
- Disabling protection based only on the word REST: inspect how every accepted credential reaches the endpoint.
Check your understanding
Answer these without looking back at the article.
- If you store the JWT in an HttpOnly cookie, do you need CSRF protection again?
- Why is it safe to disable Spring Security's CSRF filter for a stateless JWT API?
- What's the trade-off between storing a JWT in localStorage vs a cookie?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.