After reading this question, if my understanding is correct, the server sends the CSRF token downstream as a cookie. On first glance, that would seem to defeat the purpose of the token since all cookies are sent by the browser even if the request isn't of the same origin.

However, in order to write it as a custom field, you need to read it first, which you can do only if you are same-origin. So the request proves it comes from code that has "the right to read" from the cookie jar - which is different from the browser sending it on your behalf.

But I am not sure if I understood it correctly. Is that how it works?


2 Answers 2


Yes, that is correct.

The Same Origin Policy prevents other domains from reading the actual cookie value.

In an CSRF attack, the browser automatically sends cookies. Even though the attacker can't read these cookies, she can still use them by sending a cross-site request.

If you require all requests with side-effects to have a verified value that is sent outside of the cookie mechanism, then this mitigates CSRF because the attacker has no way of knowing it.


The intention with sending a custom header such as X-CSRF-Token as well as a cookie is that the technique, called double submit, will mitigate CSRF if implemented properly. The way it works is that while cookies will be automatically sent with a forced request as in the case of CSRF, the custom header will not, stopping an attacker from forcing you, the victim, to not get attacked because the server will look for both values. Double submit is used in cases where the application doesn't want to keep track of state of an anti-CSRF token.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .