Cookie-to-Header CSRF protection vs CORS

Information Security Asked by Karlis Filipsons on February 19, 2021

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

Example scenario:
A rest API called provides data to has allowlisted cross-origin requests from
Some client with an old browser that doesn’t have CORS implemented goes to From what I understand has no issues making requests to 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

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!

Correct answer by Teo Selenius on February 19, 2021

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

Answered by Sjoerd on February 19, 2021

Add your own answers!

Related Questions

Diffie Hellman c# implementation

2  Asked on January 2, 2022 by roger-far


How to know if an RFI/LFI attack was successful?

2  Asked on December 31, 2021 by user226295


Suricata and rules based on MAC address

1  Asked on December 28, 2021 by loi219


Signing CSR using an ECC keypair

2  Asked on December 28, 2021


How to identify IP from a UDP-based DoS

4  Asked on December 26, 2021 by nihas


PostgreSQL injection with basic sanitization

1  Asked on December 26, 2021 by asker-asky


Ask a Question

Get help from others!

© 2023 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP