CookieCsrfTokenRepository.withHttpOnlyFalse() stores the XSRF Token in cookies, and allows front-end to extract cookie contents using JS code. The front-end then appends XSRF Token to http header.
But what if a hacker injects some malicious JS code to read the XSRF Token in the cookie, and add the XSRF Token to http header of the forged http request, and send it? I think backend will think the request is legal. Is not that dangerous?
>Solution :
"If a hacker injects some malicious JS code", that’s a cross-site scripting vulnerability. Given most protections against CSRF, an XSS will beat it in the sense that any token can be read and used by the attacker. If there is XSS, there likely also is CSRF, it’s just not that big of a deal compared to XSS.
Having said that, there are some mitigations to CSRF that don’t actually break in case of XSS, one is checking referer / origin headers, the other is SameSite auth (session) cookies. These might bring different problems, but help separate CSRF from XSS impact, which can be a useful consideration in some special cases. However, if you have XSS, the attacker can pretty much do anything a user can do anyway, and they don’t usually need CSRF.