The concept of CORS and should I enforce an Origin header?

Question

As far as I understand CORS cannot exactly protect you in the way that you can really be sure who the caller is . Because the caller can send any ORIGIN header he wants. Actually I read somewhere you cannot set the origin header via javascript as it is a restricted header - but I'm not quite sure of that. Anyway.. if you were to implement your own HttpClient you could easily forge your origin header and therefore consume services which you are not supposed to consume.

Secondly if no Origin header is specified the request works as well . For example I use Google Chrome's Postman Extension and it doesn't send any origin headers. In fact if you try to add one manually it doesn't send it over the wire.

Therefore...

... question 1 is: Should my application deny requests without any Origin header? And...

... question 2 : How exactly does make CORS my REST service more secure?

Answer 1

There are browsers supporting CORS and not supporting CORS. (We are at the early stage of CORS, the implementations of the CORS specification across browsers are not consistent).

• Not supporting CORS means when the browser detects a cross-origin request, the request is blocked and not sent to the server.
• Supporting CORS means the browser applies the CORS policy: appends the Origin header before sending requests to the server and after receiving the response, the browser checks the Access-Control-Allow-Origin the decide whether to discard the response.

The same-origin policy is intended to reduce the risks of XSS attacks, this attack mostly happens on browsers, not likely to happen in HttpClient. The CORS policy is for relaxing the same-origin policy so that if you are the owner of both sites, you can leverage this policy to allow communications between your 2 sites.

 Tip Supporting CORS means that the browser has to apply the cross-origin security policy after it has contacted the server and has obtained the response header, meaning that the request is made even if the response is discarded because the required header is missing or specified a different domain. This is a very different approach from browsers that don't implement CORS and that simply block the request, never contacting the server.

Extracted from this book

Answer 2

The point of CORS is to prevent (or allow) Javascript running on a different domain from sending AJAX requests to your API and using the user's authenticated session cookie.

CORS cannot replace proper authentication; all does is prevent the browser from acting as a confused deputy against your existing authentication scheme.