Is there a reason why the XSRF-TOKEN has HttpOnly set to false when the default for cookies is true?

[adampatterson]

A site I work on had a security scan done through Acunetix and it was flagging the XSRF-TOKEN as missing HttpOnly

The default config in Laravel is to set HttpOnly to true.

Everything I read on the matter said that there's no benefit. With that in mind, is there a reason not to set HttpOnly to true?

newCookie in Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php#L212 sets HttpOnly to false.

I fixed the scan by adding newCookie to my applications VerifyCsrfToken middleware.

Is there a negative to setting it to true?

[valorin]

The XSRF-TOKEN cookie passes the CSRF token through to the javascript layer, so tools like Axios can automatically make requests to non-GET endpoints. The HttpOnly flag needs to be disabled or the cookie cannot be accessed in JS.

If you have an SPA or use something like Inertia, you'll probably need it. If not, you can disable it.

[incon]

The XSRF-TOKEN is encrypted. The plaintext token is saved to the session. csrf_token() is used when you want to provide the CSRF token to the client. Does the XSRF-TOKEN cookie even need to be sent to the browser at all?

[incon]

The encrypted cookie can only be reused as a HTTP header and not as a _token field

[incon]

I'm guessing providing non HTTPOnly cookies and having known cookie keys opens you up to XSS attacks out of the box.

[incon]

I also feel the token should also be saved as a hash of the token.

[valorin]

Non-HttpOnly cookies allow javascript to read their cookie values, but this doesn't cause XSS on it's own. You'd still need to exploit an XSS vector to read the cookie values.

If an attacker were to get XSS on your site, sure they could easily grab the XSRF-TOKEN token to make requests to the server - but they could easily grab the CSRF token from any of the fields on the page too. Once an attacker has XSS, it's already too late for CSRF tokens to do anything. They protect against a different form of attack.

I also feel the token should also be saved as a hash of the token.

Yep, you could store a hash of the token instead of an encrypted version. Or you could store a completely different unique token. It doesn't really matter what the token is, as long as it's cryptographically secure, unique, and unguessable. An attacker still needs to obtain it before they can use it in an attack.

Does the XSRF-TOKEN cookie even need to be sent to the browser at all?

If you don't have a JS frontend that needs to send requests, then no, you don't need it. It's only there as a convenience helper for front end scripts that need to make requests to the backend.

[adampatterson]

Thanks so much for the information!

I had to dig into my project history to remember why I asked this. A client site has Content Security Policies and the audit scan would flag the cookies as insecure.

I don't recall if we ended up making any adjustments and to my knowledge the scans stopped warning us. There's a good chance that they identified the false positive and addressed it. It's also possible that we read it from a meta tag.