CORS (cross-origin ressource sharing) can be used to protect webapps from CSRF, before accepting a request, the server verifies that the host specified in the Origin header is among the hosts allowed in CORS Access-Control-Allow-Origin header.

if so, then can we bypass the CORS protection by setting a custom Origin header in the CSRF exploit ? example :

header('Origin: www.already-allowed-website.net');
/* the rest of a simple POST CSRF exploit... */

2 Answers 2


No, because you're adding a header to a response, not to a request: when loading your CSRF page, your browser would see a response which was something like:

HTTP/1.1 200 OK
Date: Mon, 11 Sep 2017 09:42:49 GMT
Connection: close
Origin: www.already-allowed-website.net

... web page content ...

The "Origin" header doesn't make any sense in this context, but you can add it via PHP or other server side languages if you want to.

Then the browser would construct the actual CSRF payload, and send a request with whatever Origin header the browser wanted to set, hopefully ignoring any attempts to override it.

There is a list of what headers you can set in XHR requests at https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

  • thanks, I have another question please, when the Origin isn't allowed, the server doesn't process the request ? or the client browser doesn't send it primarily ? (after knowing the allowed hosts from Access-Control-Allow-Origin)
    – Reda LM
    Sep 13, 2017 at 15:50
  • Origin is only set by clients, in requests. This is usually the browser, and it simply ignores any attempts by website code to set it - it might set it to a browser selected value, or not set it at all, depending on context. This is usually before the Access-Control-Allow-Origin header is known to the client - although it's fairly common for Access-Control-Allow-Origin to reflect the value provided in Origin, the reverse of your scenario.
    – Matthew
    Sep 13, 2017 at 16:01
  • I mean if the Access-Control-Allow-Origin contain good.com, and a request if about to be sent from evil.com, in this case the client browser will not send the request or he will send it and then the server will reject it ?
    – Reda LM
    Sep 13, 2017 at 16:31
  • Doesn't "CS" stand for "cross-site" rather than for "client-side"? fr.wikipedia.org/wiki/Cross-site_request_forgery
    – jub0bs
    Apr 5, 2019 at 14:05
  • 1
    @jubobs Yes. I was clearly not paying attention when I wrote this... Mind you, it took 18 months for anyone to notice! I am guessing I'd just come out of a conversation about SSRF, where SS does stand for Server-Side...
    – Matthew
    Apr 5, 2019 at 14:11

It does not matter what Origin header you set in the response from the server to the browser as you do in your example with server-side PHP code. The browser does not care about this header.

Relevant for CORS is only the Origin header sent by the browser to the server. If you would be able to fake this from inside the browser you could bypass the protection. But, Origin is one of the headers which can not be changed within XHR or similar requests so such a bypass should not be possible.

You must log in to answer this question.

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