What is the point of X-CSRF-TOKEN or X-XSRF-TOKEN, why not just use a strict same site cookie?

Question

Frameworks such as laravel and others require you place the csrf token in your HTML forms.

However at the same time laravel comes by default with the VerifyCsrfToken middleware that automatically creates a X-XSRF-TOKEN cookie with the csrf token on every response. This cookie is used for ajax requests and is automatically added to the header for axios for example.

I am wondering why is it required to add the csrf token to every HTML form. Why could you not just use the already existing X-XSRF-TOKEN cookie to validate the csrf token. I understand there is the issue of same site cookies, and if your csrf cookie is set to lax or none the cookie would be sent from an external site if they would POST to my site. However this issue can be solved by setting the same site to strict then there would be no need to set the csrf token on every form which is kind of annoying to do and remember.

Is there some security concern I am missing on why we just cant use a strict cookie for validating the csrf token?

Grolier

Answer 1

An X-CSRF-Token protects users against unwanted execution of modifying requests, which are of interest for their side effects (the changes which they make to the server, or the database), not for their response, which the attacker cannot read anyway, by virtue of the CORS protocol.

A same site cookie would protect even against execution of navigation requests, which do not change anything on the server, but only read data (including X-CSRF-Tokens for subsequent modifying requests), which is then displayed in an HTML page. For example, if stackoverflow.com had same site session cookies, you would not be able to navigate from your webmail site via a mailed link to this StackOverflow question and immediately click to upvote it, because the session cookie would not be included in the navigation request, therefore you would not be logged on at first.

Note also that same site cookies are excluded from the first request to the target site, but if the target site executes an HTML-based (rather than HTTP-based) redirect, the second request includes the cookie, see SameSite=Strict cookies and cross-site requests with redirections.

Rampage

I see, so in the case the crsf cookie is set to same site strict when the user comes from an external site, they will not be able to upvote right away since the cookie was not sent due to being strict. They would have to refresh the page first in order to get the crsf cookie. It's inconvenient for developers to always set it on every form, but I guess users inconvenience is a higher priority – Grolier

Answer 2

SameSite cookies do indeed provide significant protection against CSRF attacks. But it's always better to put an explicit counter-measure in place - that is provided by anti-CSRF tokens.

For one thing, SameSite uses a notion of "registerable domain" so it does not protect you against subdomain hijacking

Finally, for these topics I very much recommend an excellent book Api Security in Action - they discuss CSRF and related topics in Chapter 4.

Wellspoken

I understand the benefits of anti-CSRF tokens, what I don't understand is the purpose of including them in the headers for ajax requests instead of just sending the cookie directly as a same site strict cookie. Are there any security concerns in doing that? Regarding subdomain hijacking it could be done as well with the headers in an ajax request so I can't see much difference in using cookies vs using the headers. – Grolier

Because you want a proof that it's a genuine client that's sending the request, not an attacker bypassing the security measures. If you used cookies, you would be vulnerable to subdomain hijacking as I said above. It's a problem with browsers sending cookies automatically. To fix that we normally render anti-CSRF tokens inside the HTML page as a hidden input field but with single page apps communicating through API you don't have HTML so you send it in a header and then verify that the client actually sends the token back when they do a POST request. – Wellspoken

Again, this is all discussed in the book - much more clearly and with way more details. – Wellspoken

Answer 3

there would be no point in validating csrf token through cookies. That's the problem we are trying to solve. If csrf token was sent and validated as a cookie, it also could be sent, and is sent in cross site request. But when doing cross site request, as far as I know, attacker can't read that cookie with js and put it inside the form, only we can access that cookie with js. That's because when we set a cookie we specify domain attribute, and that cookie can be read with js, only on that particular domain. That's the reason why that cookie is not http only, and why we include it inside forms.

Stead