Skip to main content
typo
Source Link

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.

From the accepted answer:

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 localStorage vs cookie IMO. Practically speaking, isn't it mostly the same ? If the attacker is able to access your localStorage and send a request with the token to his own server, he most certainly can send requests on your behalf to the application server through that same 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.

Answer : If you store the token in the localStorage and append it to your requests with JS, it would automatically guarantee CSRF protection (by the nature of the attack)

Addendum : As of whether it is more safe to use http-only cookies rather than localStorage (making it seem like this way of having CSRF protection would create a problem in case of XSS) : it is actually not. It would just make it a tiny bit harder for the attacker who is in control of JS on your site through an exploited XSS. @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)

Source Link

From the accepted answer:

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 localStorage vs cookie IMO. Practically speaking, isn't it mostly the same ? If the attacker is able to access your localStorage and send a request with the token to his own server, he most certainly can send requests on your behalf to the application server through that same 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.