title: CSRF protection with CORS Origin header vs. CSRF token
body: <p>This question is about protecting against Cross Site Request Forgery attacks only.</p>
  <p>It is specifically about: Is protection via the Origin header (CORS) as good as the protection via a CSRF token?</p>
  <p>Example:</p>
  <ul>
  <li>Alice is logged in (using a cookie) with her browser to <code>https://example.com</code>. I assume, that she uses a modern browser.</li>
  <li>Alice visits <code>https://evil.example</code>, and evil.example's client side code performs some kind of request to <code>https://example.com</code> (classic CSRF scenario).</li>
  </ul>
  <p>So:</p>
  <ul>
  <li>If we don't check the Origin header (server-side), and no CSRF token, we have a CSRF security hole.</li>
  <li>If we check a CSRF token, we're safe (but it's a bit tedious).</li>
  <li>If we do check the Origin header, the request from evil.example's client side code should be blocked just as well as it would when using a CSRF token - except, if it is possible somehow for evil.example's code to set the Origin header.</li>
  </ul>
  <p>I know, that this should not be possible with XHR (see e.g. <a href="https://stackoverflow.com/questions/13242049/security-for-cross-origin-resource-sharing">Security for cross-origin resource sharing</a>), at least not, if we trust the W3C spec to be implemented correctly in all modern browsers (can we?)</p>
  <p>But what about other kinds of requests - e.g. form submit? Loading a script/img/... tag? Or any other way a page can use to (legally) create a request? Or maybe some known JS hack?</p>
  <p>Note: I am not talking about</p>
  <ul>
  <li>native applications,</li>
  <li>manipulated browsers,</li>
  <li>cross site scripting bugs in example.com's page,</li>
  <li>...</li>
  </ul>