What advantages does a Cookie-to-header technique give over CORS in a cross-origin request scenario?

Example scenario: A rest API called api.com provides data to good.com. api.com has allowlisted cross-origin requests from good.com. Some client with an old browser that doesn't have CORS implemented goes to evil.com. From what I understand evil.com has no issues making requests to api.com and retrieve any CSRF tokens from the requests since CORS isn't implemented in the browser the client uses.

To me, it looks like Cookie-to-header CSRF protection doesn't provide any additional protection over what CORS already provides.

2 Answers 2


If I understand your question correctly, you are trying to compare things that are not comparable.

"Cookie-to-header" is a defense mechanism against CSRF attacks, although not a very good one as it relies on an attacker not being able to inject cookies into the user's browser. Better to tie a unique CSRF token to the user's session and put that value in forms and ajax requests. In any case, you shouldn't implement the mechanism yourself but use a modern web application framework that can do it for you.

Same Origin Policy is the core of the web browser security model and essentially says that:

  1. Websites from different origins (different URL host, port, or protocol) can freely send credentialed (that is, including session cookies) GET, POST, HEAD, and OPTIONS requests to each other.
  2. Websites from different origins however cannot read the responses of those requests. Though there are exceptions of sorts that allow for executing scripts and rendering images for example.

CORS (Cross-Origin Request Sharing) is not a security mechanism per se, I would rather call it an insecurity mechanism. It simply allows for an individual website to opt-out of the same-origin policy for some URL address/addresses.

About the compatibility, even IE10 supports CORS so I wouldn't worry about that. But yes, like said, even if CORS is not supported it just means that the same-origin policy will remain effective.

So, a bad CORS policy and CSRF are two distinct vulnerabilities, you can have one, none, or both.

CSRF vulnerability = You are not using CSRF tokens so that POST requests from malicious websites (which are allowed by the same-origin policy whether you use CORS or not) can make unwitting changes in your web application on the logged-in user's behalf. Those websites are still not allowed to read the responses, but they won't have to.

CORS vulnerability = You are allowing other websites to do something that breaks the same-origin policy. The worst thing you can do is enable the "allow credentials" for arbitrary/untrusted domains, which will let malicious websites use your web application on your user's behalf whether you use CSRF tokens or not because CSRF protection relies on the same-origin policy for it to work.

I hope that clears things up!


CORS relaxes the same-origin policy. If a browser does not have CORS support, it enforces the same-origin policy. So evil.com can not read the CSRF token from api.com.

  • Thanks, I didn't know it falls back to same-origin. In that case, does having Cookie-to-Header protection bring any additional protection over what CORS and same-origin policy offers? Feb 10, 2021 at 8:58

You must log in to answer this question.

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