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:
- 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.
- 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!
