Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
How can the Same origin policy protect something if you can bypass it via Cross Origin Resource Sharing headers? And why are those assigned by the server which is tried to access and not by the user?
Where is the risk of a Cross Origin Resource Request?
CORS is a way to deliberately and controllably punch holes in a site's own protections, specifically in the protections provided by the same-origin policy (SOP). You can only abuse CORS to attack another site if the other site has lowered its defenses too far.
I'm going to lay out some scenarios that may help you understand. Assume, for these scenarios, that there are adequate protections against CSRF and no XSS vectors or other conventional cross-site attacks possible.
Site V is a valuable target. That is, it's a web application that users sign into, and it holds access to valuable data or is otherwise something people would like to compromise the users of.
Site P is a trustworthy partner of site V. It needs access to some data from the user's session on V, but it is run by a party that V's owners trust.
Site M is a malicious website. Its purpose is to lure users who are currently signed into site V, and try to compromise their sessions.
User U is currently logged into site V, but also visiting site M. They are using a typical web browser, which supports SOP but also CORS.
Scenario 1: No CORS in use. Site M can make U's browser send all the requests it wants to site V (although non-simple requests get no further than the CORS preflight), but site V doesn't send back and CORS headers. Because of the SOP, the browser drops the responses to these requests, and M can't see anything. On the other hand, site P can't either.
Scenario 2: Overly permissive CORS. Site V's administrator has foolishly set up their site to return Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: <X> for any Origin: <X> in an incoming request. In other words, site V allows authenticated CORS requests from any origin. This allows site P to retrieve data from V, but it also allows every other site to do so as well; in effect, site V has turned off the protections it would normally get from SOP. Site M causes U's browser to send authenticated CORS requests to V, V responds including the CORS ACAO and ACAC headers mentioned above, and site M steals all of U's data out of V.
Scenario 3: Securely-configured CORS. Site V's administrator wants site P to be able to see data from site V, but no other site. Thus, incoming requests specifying Origin: P receive CORS headers that allow access (Access-Control-Allow-Origin: P and Access-Control-Allow-Credentials: true), and site P is allowed to make CORS requests to V and retrieve data. However, requests originating from all other sites receive no CORS headers in response at all, or perhaps just always receive Access-Control-Allow-Origin: P which doesn't do the request-initiating sites any good because they aren't site P. Thus, site M's attempt to read data out of V is again blocked by SOP.
