Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?
  • like image 924
    lapsus Avatar asked Feb 15 '13 16:02

    lapsus


    People also ask

    Does CORS require a header?

    Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

    Is it a good practice to enable CORS?

    CORS isn't bad practice. It is supported on all major browsers, and more and more APIs are supporting it. In fact, if you have a public resource that is not behind a firewall, it is safe to put the Access-Control-Allow-Origin: * header on the resource.

    When should you enable CORS?

    Cross-origin resource sharing (CORS) is a browser security feature that restricts cross-origin HTTP requests that are initiated from scripts running in the browser. If your REST API's resources receive non-simple cross-origin HTTP requests, you need to enable CORS support.


    2 Answers

    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

    like image 108
    Khanh TO Avatar answered Nov 15 '22 23:11

    Khanh TO


    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.

    like image 28
    SLaks Avatar answered Nov 16 '22 00:11

    SLaks