Why pass X-XSRF-TOKEN in it's own header when a 🍪 will do?

[ospira]

Hello, today I was experimenting with headless Laravel using Sanctum and Fortify. My plan was to do some basic testing of the auth flow before embarking on a Next.js frontend to consume the Laravel API. I'm on the latest version of Laravel, developing locally using Sail.

Anyway, I was reading about the Sanctum workflow and getting stuck after trying to hit the Laravel Fortify /login route after hitting /sanctum/csrf-cookie, with a CSRF token mismatch error. I read up on this and saw lots of people had this problem. I saw in the response from /sanctum/csrf-cookie that the following cookies were being set:

laravel_session

and

XSRF-TOKEN

I was using the fetch API, including credentials, meaning I saw in the subsequent call to my /login route that the XSRF-TOKEN cookie was being sent in the request headers. So, I was confused because there is the cookie/token that is being set from /sanctum/csrf-cookie and here it is being sent in the request headers to /login so why isn't it working? Well it turned out it's because the framework isn't checking it from the cookie, despite setting it in a cookie after the initial GET request to /sanctum/csrf-cookie .

Here is the relevant framework code:

https://github.com/laravel/framework/blob/8.x/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php#L151-L164

If at the bottom of that (above return $token;) I do something like:

$token = $request->cookie('XSRF-TOKEN'); then my fetch call worked.

Without this intervention, I would have to get the cookie in javascript and add it to the header, like this:

fetch("http://localhost/api/auth/login", { //login route (Fortify)
  headers: {
      'Accept': 'application/json',
      'Content-Type': 'application/json',
       'X-XSRF-TOKEN': getCookie('XSRF-TOKEN')
   },
   ...

So my question is, why is this necessary? I know axios and others according to the docs might do this for me automatically, but why? If it's already in the cookie, and the cookie is being set and sent, why can't the framework check for my cookie instead of in a separate part of the header?

[ospira]

Ok nvm I did some more framework agnostic research and I think I understand why this is done now.

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Cookie-to-header_token

Because if it just read the cookie that would ruin the point of CSRF protection.