I have a system which needs to do cross-origin requests and having trouble under

Question

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.

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.

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)?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.