Why is the newCoockie() parameter httpOnly setted false?

[JoaVitoTavares]

In the class /Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php the newCoockie method is setted httpOnly to false, someone can tell me why please?
protected function newCookie($request, $config) { return new Cookie( 'XSRF-TOKEN', $request->session()->token(), $this->availableAt(60 * $config['lifetime']), $config['path'], $config['domain'], $config['secure'], false, false, $config['same_site'] ?? null ); }

[valorin]

The XSRF-TOKEN cookie is used to pass the CSRF token to the javascript toolkit, so it can make POST requests with valid CSRF tokens without needing to find a CSRF field on the page and extract the token manually.

[valorin]

I'm not sure why you'd want it to be adjustable?

The only purpose of the cookie is to pass the CSRF token to JS. Making it httponly would prevent that from happening, making the cookie pointless.

[JoaVitoTavares]

But this isn't a secure problem? I tested the secure of a laravel application and i had the following problem:

I utilized the pentest-tools.com/ this security assessment.

My professional colleagues realized a test in this application that i mentioned earlier, they overwrote the httpOnly parameter in the newCoockie method to true

And after that the new secure test showed that the 'httpOnly' flag was no longer present.

PS: Please note that in our session/config httonly is set to true.

[henzeb]

But frontend needs to be able to access the cookie so they can put it in the header, as per the docs. https://laravel.com/docs/10.x/csrf#csrf-x-xsrf-token

With http_only you are not preventing it from sending it through https, it prevents you from accessing it.

Why would that be a security problem?

[valorin]

But this isn't a secure problem? I tested the secure of a laravel application and i had the following problem:

This is a False Positive and can be safely ignored. This cookie is intentionally set without httponly because it is required by the javascript to work.

Automated security scanners are ignorant of implementation details like this, so although they work really well for finding low-hanging fruit, they also find things that look like security risks, but really aren't.
I'm a penetration tester, so I'm always seeing this popup in scanners and I advise my clients to ignore it.