From the accepted answerAnswer :
With a cookie you can set the http-only flag, which prevents the application from reading the cookie after it is set. As a result, in the event of an XSS attack, the attacker can still make calls on your behalf, but they can't walk away with the authorization token all together
This is a weak argument for If you store the token in the localStorage vs cookie IMO. Practically speakingand append it to your requests with JS, isn't it mostly the samewould automatically guarantee CSRF protection ? If(by the attackernature of the attack)
Addendum : As of whether it is ablemore safe to access youruse http-only cookies rather than localStorage and send(making it seem like this way of having CSRF protection would create a request withproblem in case of XSS) : it is actually not. It would just make it a tiny bit harder for the token to his own server, he most certainly can send requestsattacker who is in control of JS on your behalf to the application serversite through that samean exploited XSS. So cookie or storage, you're compromised. @bobince have explained that with better words : Does setting httponly prevent stealing a session using XSS?
XSS is application level vulnerability, but its effects can be mitigated by limiting the power of the token through the usage of claims (restrict to minimum necessary)
Therefore use the token through storage/header to have CSRF protection at least.