CSRF Token in REST API with authentication

Question

I understood the purpose of the CSRF Token protection.

However, I think this protection is useless and we should remove it in the case of a REST API requiring an authentication token in the header for each action.

This way, even if Mallory forges a malicious HTML link to Alice, the attack can not be done. The reason is that:

Alice keeps her authentication information in a header key that Mallory don't know. And unlike a cookie, Alice's browser doesn't submit this authentication token automatically.

So in this context, I would like to have you point of view about the question: can we remove a CSRF token protection from this kind of API design?

Arbe

Answer 1

Yes, you don't need CSRF protection when using a bearer scheme authentication as the browser does not automatically add the Authorization header to the request.

You do need CSRF protection for cookies, basic, Windows, digest and client certificates authentication schemes as these are automatically added by the browser.

See also Dominick Baier's article on implicit vs explicit authentication: http://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/

Elsworth

But in a typical web app wouldn't you store the token in a cookie and then set it as the Authorization header for each request? Otherwise the user's session doesn't persist and they need to login again if they close the window. – Brent

Answer 2

Theoretically, you don´t need CSRF protection as you described. But one of my main concerns is where to store the access token. The local storage of the browser does not provide a good security. So it´s often stored in cookies. And so, the CSRF vulnerability comes back.

Jean-Christophe Baey described in his article a two-cookie mechanism to prevent access tokens from CSRF and from being stolen by XSS.

To sum that article up: The payload of the access token is stored in a cookie that is accessibly by JavaScript. The signature of the access token is stored in a cookie that is NOT accessible by JavaScript. The client reads the payload from the cookie and passes it in the Authentication-Header to the server. The server validates the token based on the signature which is sent in the HttpOnly cookie.

So, its CSRF-save and an attacker cannot steal the entire token via XSS because there is no JS-access to the signature.

Edit:

In the meantime, modern browsers support the SameSite cookie property. If you set this property to Strict, the cookie will only be sent to the server if the current site is equals to the origin of the cookie.

Brice