0

From what I've always understood, your browser decided whether or not to allow Cross Origin Requests.

The way I understand it is as follows:

Your browser requests a certain website from a server, say www.billswebsite.com. The server sends back a page. If the page tries to make your browser request data from somewhere else, something malicious might be going on so your browser decides for you not to make requests to anywhere but the website you initially entered.

However, then I came across this website http://jsonplaceholder.typicode.com/ which claims that on their end, they have turned off restrictions on CORS.

I don't get how they did that. Why would the responsibility in such a thing lie in the hands of the provider? Any malicious website could just allow CORS and steal your data, or at least point your computer to places you don't want to go.

Can someone please clarify how this whole thing works?

CodyBugstein
  • 21,984
  • 61
  • 207
  • 363
  • Your browser decides, but it's decision-making process goes "Did this cross-origin site serve me appropriate CORS headers? If so, allow; if not, deny." Also, CORS *exposes* data, so the only security concern is that CORS can be used to *negligently give away* your data by the service that provides it (e.g., gmail.com allows some/all origins to access your inbox), but it cannot be used by a totally unrelated origin to *steal* your data (e.g., some service using CORS doesn't mean they can suddenly access your `gmail.com` inbox without CORS say-so from `gmail.com`). – apsillers Dec 08 '14 at 17:18
  • the server which serves up the JS code is the one that says "this code is allowed to make cross-domain requests to the following domains". that permission doesn't apply to any other js files loaded from other sites/servers. if it did, then there'd be no point in having a cross-domain security policy. – Marc B Dec 08 '14 at 17:22
  • @MarcB CORS headers apply to the resource being requested. If a script requests `http://example.com/foo.txt`, then the `Access-Control-Allow-Origin` header in the *response from that particular request* determines whether the script can read `foo.txt` or not. CORS access is not determined by the server that serves up the JS code, it's determined by the server that serves the resource being requested (e.g., by Ajax). Your comment seems to have the right idea, but I'm concerned that it may be confusing (or have confusing assumptions) for the OP. – apsillers Dec 08 '14 at 17:28

1 Answers1

2

When a server uses CORS, it's opening a door to cross-origin access to its own resources. When Site A serves CORS headers, that means some other origin can read resources on site A.

Your concern that

Any malicious website could just allow CORS and steal your data

is a bit like being worried that

Any evil criminal who owns a house could leave his own doors unlocked and then easy walk into your home and steal things

The criminal has left the doors of his own home unlocked; your doors are totally unaffected. If an evil site serves CORS headers, then other origins can access the resources on that evil site; this is not a bidirectional permission.

Whenever a browser script requests a cross-origin resource with AJAX, the server who owns the resource may serve an Access-Control-Allow-Origin CORS response header to allow cross-origin access to that specific resource. When the browser gets the response, it checks if the requesting script has been run from an origin allowed by the CORS response. If there's a match, the script is allowed to see the response; if not, it is denied.

For example, billswebsite.com runs a script that tries to fetch http://example.com/foo.txt. The example.com server can send an Access-Control-Allow-Origin header in the response when it serves foo.txt. When the browser gets the HTTP response, it checks that the Access-Control-Allow-Origin is either * or billswebsite.com. If the Access-Control-Allow-Origin header doesn't match, or is missing entirely, then the script on billwebsite.com doesn't get to read the response.

apsillers
  • 112,806
  • 17
  • 235
  • 239
  • Thanks for the analogy, I love analogies. Just to be sure, can you define `origin`? – CodyBugstein Dec 08 '14 at 17:55
  • @Imray An origin is **domain** plus **scheme** plus **port**: "[Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages.](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)" See also my answer on [Does Cross-Origin Resource Sharing(CORS) differentiate between HTTP AND HTTPS?](http://stackoverflow.com/a/19542686/710446) for a diagram. – apsillers Dec 08 '14 at 17:57