From what I understand about CORS, this is how it works: I have a site foo which serves a page X. X wants to post data to another domain bar. If bar is CORS enabled (its headers produce Access-Control-Allow-Origin foo) then page X can now send data to bar.

As I understand to get CORS to work it's all about settingit up on bar, and has nothing to do with foo. It's all about making sure bar doesn't accept requests from any old domain.

However this really doesn't make sense to me. I thought CORS was designed to enable foo to dictate who X is allowed to municate with. If we go back to the previous example but this time X is promised by dodgy script so that it sends data secretly to evil, how is CORS going to stop that? evil is CORS enabled, and set to *, so it will accept requests from anything. That way a user thinking they using a site foo, are unwittingly sending data to evil.

If it is really all about bar protecting itself, then why does it make the browser enforce the policy?. The only conceivable situation in which this makes sense if you have evil serving up page Y that impersonates foo, that tries to send data to bar. But CORS is enforced by the browser, all you'd have to do is make evil a proxy that sends faked origin requests to bar (data goes from Y to evil, evil sets its fake origin to foo then sends it to bar).

It only makes sense to me if it works the other way round. foo is CORS enabled, and its headers are set to Access-Control-Allow-Origin bar. That way rouge scripts would get denied access evil by the browser. It then makes sense for the browser to enforce the policy because its running the scripts that could go rouge. It won't stop rouge sites from trying to send rouge data to bar, but bar can protect itself with a username/password. If foo has endpoints that it's expecting data back from X, then you can embed tokens into X, to ensure evil doesn't send data to it instead.

I feel like I'm not understanding something fundamentally important here. Would really appreciate the help.

From what I understand about CORS, this is how it works: I have a site foo. which serves a page X. X wants to post data to another domain bar.. If bar. is CORS enabled (its headers produce Access-Control-Allow-Origin foo.) then page X can now send data to bar..

As I understand to get CORS to work it's all about settingit up on bar., and has nothing to do with foo.. It's all about making sure bar. doesn't accept requests from any old domain.

However this really doesn't make sense to me. I thought CORS was designed to enable foo. to dictate who X is allowed to municate with. If we go back to the previous example but this time X is promised by dodgy script so that it sends data secretly to evil., how is CORS going to stop that? evil. is CORS enabled, and set to *, so it will accept requests from anything. That way a user thinking they using a site foo., are unwittingly sending data to evil..

If it is really all about bar. protecting itself, then why does it make the browser enforce the policy?. The only conceivable situation in which this makes sense if you have evil. serving up page Y that impersonates foo., that tries to send data to bar.. But CORS is enforced by the browser, all you'd have to do is make evil. a proxy that sends faked origin requests to bar. (data goes from Y to evil., evil. sets its fake origin to foo. then sends it to bar.).

It only makes sense to me if it works the other way round. foo. is CORS enabled, and its headers are set to Access-Control-Allow-Origin bar.. That way rouge scripts would get denied access evil. by the browser. It then makes sense for the browser to enforce the policy because its running the scripts that could go rouge. It won't stop rouge sites from trying to send rouge data to bar., but bar. can protect itself with a username/password. If foo. has endpoints that it's expecting data back from X, then you can embed tokens into X, to ensure evil. doesn't send data to it instead.

I feel like I'm not understanding something fundamentally important here. Would really appreciate the help.

• javascript
• jquery
• cross-domain
• cors

Share Improve this question Follow asked Dec 20, 2014 at 18:36 user1830568user1830568 50511 gold badge77 silver badges1212 bronze badges 1

• I was thinking exactly the same thing - every explanation of CORS should have a disclaimer which mentions how it can be circumvented via a proxy. I'm not sure how detecting this kind of attack would be so easy either. Hopefully you notice and care like TJ says, but I imagine in most cases it could easily go unnoticed. – Rene Wooller Commented Nov 19, 2015 at 22:42

Add a ment  | 

2 Answers 2

Sorted by: Reset to default 5

However this really doesn't make sense to me. I thought CORS was designed to enable foo. to dictate who X is allowed to municate with.

No, it's about bar. controlling use of its content.

But CORS is enforced by the browser, all you'd have to do is make evil. a proxy that sends faked origin requests to bar....

Yup. And if you do, and the people at bar. notice and care, they disallow requests from your server. You move it, they disallow the new one. Whack-a-mole time. But painful as that game of whack-a-mole is, it's a lot less painful than if the requests e directly from each individual user of foo., from their desktop.

Having foo. enforce what foo. can do doesn't make any sense. foo. already enforces what foo. can do, because it's foo. that serves foo.'s content and scripts.

It isn't about Foo., nor about Bar.. It is about user.

There are two things that CORS protects against. The first is access to resources behind the firewall. The second are resources that are normally protected, unless a request is sent from a browsers with authentication or other sensitive data cookies.

CORS is a Browser technology, with support from servers, that allows foo limited freedom to call outside of its domain. It is a restricted hole punched in the restriction against cross domain scripting.

Anyone can fake the ORIGIN header and create a CORS preflight or simple request -- Of course, anyone can directly connect to the Bar server directly and make the requests without using CORS at all. Any browser can directly connect to bar. and get data. But a modern browser will not run a script from foo. that access a bar. resource. People visiting websites are protected against visiting a site designed to exploit cookies or the fact that the browser is behind the corporate firewall.

So the accepted answer is WRONG. It isn't about bar. protecting its resources -- it does this through authentication and authorization. You don't have to create a proxy to send CORS requests -- you create a proxy to strip out the CORS requests (automatically responding to the preflight request, and returning the proper headers to the browser, but sending a normal request to bar.). But you will still need authentication to get bar.'s resources, and foo. would still need to somehow get you to install a proxy to exploit the cross domain scripting hole that CORS protects against.

But the concluding sentence is correct -- foo. isn't in control of the resources -- it is the browser, with a quick check with bar. to ask it if this is something that was intended.

From the OP:

If it is really all about bar. protecting itself, then why does it make the browser enforce the policy?. The only conceivable situation in which this makes sense if you have evil. serving up page Y that impersonates foo., that tries to send data to bar.. But CORS is enforced by the browser, all you'd have to do is make evil. a proxy that sends faked origin requests to bar. (data goes from Y to evil., evil. sets its fake origin to foo. then sends it to bar.).

evil. can already contact bar. -- just like any human using a browser can (or curl or wget, etc). The issue is can evil. force your browser to connect to bar., which may have IP filters, cookies, firewalls, etc protecting it, but javascript can connect to using your browser. So the Browser is the thing that protects the user. By disallowing cross domain scripting. But sometimes it is useful (ex: google apis, or a bank connecting to a bill paying service, etc) to cross domain script. CORS tells the browser that it is OK in this instance.

That isn't to say that there are no holes, or the the standard is the best, or that there aren't holes in implementation in the browser, or that sites are too permissive. But those are different questions...