What is the applicability of CORS?

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

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

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.

Filed under: softwareengineering - @ 11:18

Thẻ: http, javascript, web-applications

Thiết kế website giá rẻ

Danh mục

What is the applicability of CORS?