Information Security
Do I need CSRF token if I'm using Bearer JWT?
Context: Angular site is hosted on S3 behind CloudFront, separate from Express server that is used as API and almost all requests are XMLHttpRequests. All requests are sent without cookies (withCredentials = false by default) and I use JWT Bearer token for authentication by taking it from cookies in angular and placing to Authorization header (This technique is kind of what is described in CSRF Wiki page).
On Express site I do not allow Cookie header in Access-Control-Allow-Headers.
Cookies have secure: true flag, and are NOT httpOnly because I need to manually access them in angular.
Also I've read in this Medium article that JSON-Web-Tokens(JWT )/Bearer Tokens
is without a doubt one of the best methods of preventing CSRF
Question 1: Will I add extra security if I'll add X-XSRF-Token header to each request and for example make the mechanism stateless by checking for that same value in JWT payload? (I'we read about it in this thread)
Question 2: Do I actually need extra security efforts agains CSRF taking all that I described?
Solution
This is relevant but doesn't necessarily answer 100% of your question:
https://security.stackexchange.com/a/166798/149676
The short of it is that as long as authentication isn't automatic (typically provided by the browser) then you don't have to worry about CSRF protection. If your application is attaching the credentials via an Authorization header then the browser can't automatically authenticate the requests, and CSRF isn't possible. Therefore, I would re-word the quote from your article slightly: it isn't that Bearer Tokens are the best defense against CSRF attacks, but simply that CSRF is an attack vector that specifically attacks requests where the browser automatically provides authentication (typically cookies and basic authentication), and so CSRF doesn't matter if the browser can't authenticate you.
You should probably make sure and verify, server-side, that your application isn't silently falling back to cookie validation if the Bearer token is absent. I could see something like that squeaking into an application by accident, and since the cookies will get sent along whether you want them to or not, it could result in an inadvertent CSRF vulnerability on a page that is was "supposed" to be immune to CSRF.
As a result, I think both your questions one and two can be answered the same way. If you only use authentication via Bearer tokens and not via cookies, then there is no concern of CSRF vulnerability, and no extra steps are required for security.
Comments (5)
- +2 – It's Incorrect to say that "as long as authentication happens in the header and not by cookies that you don't have to worry about csrf-protection." Basic auth happens by headers and is vulnerable to csrf. Similarly, digest authentication, ntlm, negotiate and certificate auth can all be vulnerable to crsf. CSRF must be mitigated whenever the browser automatically sends the authentication, because then a malicious third-party can simply issue a request to the server from the user's browser and the browser will automatically send the credentials so the server can't distinguish without "help". — Jan 06, 2019 at 18:48
- +4 – @Nathan The answer I linked to mentioned exactly your point and some of those exceptions (in fact I mentioned Basic authentication as an exception in my answer). I didn't mean to imply "header auth = secure" but rather "if you are setting headers to provide auth then you are secure". Yes, there are some header-based authentication systems that a browser (or authentication server) will automatically provide, and then you have to worry about CSRF. — Jan 06, 2019 at 19:01
- +0 – So If I put the JWT in cookie for future use but when sending the request, I take it from cookie and put in custom header, and at server side I am checking using only that custom header, so I am safe to both XSS and CSRF attack right? — Feb 19, 2021 at 12:15
- +1 – @mss That would protect you against CSRF. It would not protect you against XSS (not that anything fully can) because in order to get it out of the cookie to attach it to the custom header, you would have to disable the
httpOnlyflag. This means that an attacker could grab it during an XSS attack — Feb 19, 2021 at 18:01 - +2 – @mss encrypting the cookie contents won't get you very far because the directions on how to deencrypt it are built into the program for an attacker to read to. It may slow someone down a little bit, but not really. Nothing is ever perfect, so the trick is to find a balance that works well for you. That might mean just leaving off the
httpOnlyflag, or it may mean leaving it on but using a separate cookie for your CSRF check. For reference, you're basically talking about the double submit cookie CSRF protection scheme. — Feb 20, 2021 at 11:45
External Links
External links referenced by this document: