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?
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.
httpOnly
flag. This means that an attacker could grab it during an XSS attack — Feb 19, 2021 at 18:01 httpOnly
flag, 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 referenced by this document: