I have a system which needs to do cross-origin requests and having trouble understanding the relevance of CORS. At first glance it doesn't appear to provide me with any type of security I'd actually want for my service.

  1. Since CORS is honoured only on the client side my server must still make zero assumptions about the request. There is no guarantee a request is coming from a browser at all, thus CORS headers cannot be used as access control.

  2. The target server decides who is allowed to talk to it, and the origin server has no control. My JavaScript is also not secure on the client and subject to alteration. A malicious server could simply accept all CORS requests and thus all data could leak out of my application.

I see only a narrow scope of where CORS is actually helpful. This is the Facebook like scenario. Default cross-origin restrictions prevent a malicious page from making requests to Facebook on behalf of the user. CORS simply allows certain domains to do this. However, I still don't see the value in CORS here because some simple DNS setup would allow the same behaviour.

So what I am missing about CORS? In which scenarios is it relevant and advantageous to use (compared to simple DNS CNAME's)?

2 Answers 2


Every time I write a RESTful service, I throw in the CORS headers so that I can read it from an arbitrary javascript/browser application.

The reasons are:

1) CORS is all about client-side security, and has NO EFFECT on server side security. (This was the main point that confused me when I first started looking at it.)

2) I always provide some security mechanism like OAuth anyway, so that the browser's cross-origin restriction is weak and redundant.

3) A malicious user can trivially stand up a proxy service that takes requests and routes them to your service. The proxy doesn't care about the same-origin restriction, which defeats the restriction in the browser.

But for me, the short answer is, either my data is protected with some authorization scheme like OAuth, or else it's not protected and I don't care if (or actively want) an arbitrary browser comes in and gets it.

BTW standing up a proxy on the same server that serves the pages is the "other" official way to defeat the same-origin restriction. ;) I have to do that for the RESTful services I integrate with but I don't own. ...If you're doing that, just provide some limits so the proxy doesn't become a wide-open portal to your internal infrastructure.

More information on CORS headers here: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

  • 1
    This kind of supports my feeling that it's more of a fix for the broken same-origin policy than anything really substantial. If I'm writing a RESTful API I might as well just allow all incoming requests since I must have a proper authorization scheme anyways. Feb 16, 2014 at 17:02

Well, the first and most obvious scenario is when you really do want to allow everyone to call your service. Say you have a public data repository that you want to encourage other people to use and develop interfaces for. Without CORS, web apps are limited to having the user call the interface server and it making a webservice request and then responding to the user with that information -- the developer of the interface is acting as proxy, which they may not be able to afford/want to do. With CORS your repository can be accesed by anyone, and thus the interface can be pure javascript.

Secondly, your first objection is irrelevant -- while the COR headers can not be used for acces control other headers and the body of the request certainly can.

As for your second objection -- typically, you aren't sending information to the second server, you are getting information from it. And if you don't trust the second server your app doesn't have to use it.

  • This doesn't make much sense... if anyone can access any cross-domain service by utilizing cors, then what's the point of having cross-domain protection? Feb 15, 2014 at 23:12
  • None. But the browsers do it anyway, because they can't tell the difference between a web service that provides weather information or Amber alerts and a banking transaction that says to send all your money to an account in the Cayman Islands. If you could rely upon banks and everyone else to use HTTPS CORS wouldn't have been necessary (because https request could have been refused). I would bet that one of the alternatives to CORS before it got so established was to get browsers to allow XMLHttpRequests on a non-standard port.
    – jmoreno
    Feb 16, 2014 at 2:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.