On the Angular single-page application (Angular + REST API) I use JWT authentication. Let's assume JWT tokens are properly generated and really random (you can't predict it).

Is this JWT token enough protection against Cross Site Request Forgery (CSRF)? In the other words, is JWT sufficient as anti-CSRF token as well?

  • 5
    If it's JWT in an authoriation header then yes, that prevents CSRF. If it's JWT in a cookie it doesn't
    – paj28
    Commented Jan 9, 2018 at 10:37
  • @paj28 JWT usually is not a cookie, but I just wanted to check my understading of the issue with the community. Commented Jan 9, 2018 at 11:08
  • 2
    CSRF protection relies on the page sending something that content on the page can access but that external triggers cannot. It's more about how it's transmitted vs. the content (as @paj28 noted). If the CSRF token is in a cookie, that's bad, because the token will be sent automatically because of the cookie domain policy. You gain something by using a signed blob, but only if you do the much more important things around how CSRF protections work.
    – Joe
    Commented Jan 9, 2018 at 12:29

1 Answer 1


If the JWT is in a header, you should be safe. The attacker can't fool the victims browser into setting the header (unless CORS allow it, or she leverages an old Flash exploit). But lets say the attacker can control the header. Then what should she set it to? She wouldn't know.

On the other hand, if the JWT is in a cookie you will be just as vulnerable as with an ordinary session cookie. So wheater you are vulnerable or not has little to do with what kind of token you use (JWT or session ID) but more to do with where you put it (header or cookie).

Even when the authentication comes with automagic CSRF protection, you may want to consider adding a explicit CSRF protection anyway. There is always a risk that someone changes the authentication mechanism without realising it has double purposes.

  • Thanks a lot for the reply. My assumption is that the JWT token is not a cookie and by using it via headers I could consider it as an anti-CSRF protection. Commented Jan 10, 2018 at 10:03
  • 1
    Yes, you could.
    – Anders
    Commented Jan 10, 2018 at 10:07
  • @Anders, Thanks for the answer, one thing I am confused about it , even if I set the JWT in cookies for next time use, but whenever I am sending the new request, I am taking the JST from cookie and setting it in suppose authorization header(in my javascript code), and I am checking at server for this header only, isn't my web application safe from CSRF and XSS attacks. Regarding CORS allowance, unless the attacker is at the person computer, shouldn't be application again be protected against CSRF and XSS as attacker don't have access to JWT token. please let know If I am missing something?
    – mss
    Commented Feb 19, 2021 at 12:05
  • 1
    @mss (1) As long as you always check the header, not the cookie, you are protected from CSRF. (2) Yeah, even if CORS allow the attacker to set the header, a CSRF attack is not possible since the attacker does not know what JWT to use. As for XSS, that is an entirely different issue.
    – Anders
    Commented Feb 20, 2021 at 8:19
  • @Anders Thanks for clarifying, that was really helpful :>
    – mss
    Commented Feb 20, 2021 at 8:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .