What are the security risks of setting Access-Cont

Question

I recently had to set Access-Control-Allow-Origin to * in order to be able to make cross-subdomain ajax calls.
Now I can't help but feel that I'm putting my environment to security risks.
Please help me if I'm doing it wrong.

Answer 1

AFAIK, Access-Control-Allow-Origin is just a http header sent from the server to the browser. Limiting it to a specific address (or disabling it) does not make your site safer for, for example, robots. If robots want to, they can just ignore the header. The regular browsers out there (Explorer, Chrome, etc.) by default honor the header. But an application like Postman simply ignores it.

The server end doesn't actually check what the 'origin' is of the request when it returns the response. It just adds the http header. It's the browser (the client end) which sent the request that decides to read the access-control header and act upon it. Note that in the case of XHR it may use a special 'OPTIONS' request to ask for the headers first.

So, anyone with creative scripting abilities can easily ignore the whole header, whatever is set in it.

See also Possible security issues of setting Access-Control-Allow-Origin.

---

Now to actually answer the question

I can't help but feel that I'm putting my environment to security risks.

If anyone wants to attack you, they can easily bypass the Access-Control-Allow-Origin. But by enabling '*' you do give the attacker a few more 'attack vectors' to play with, like, using regular webbrowsers that honor that HTTP header.

Answer 2

Here are 2 examples posted as comments, when a wildcard is realy problematic:

Suppose I log into my bank's website. If I go to another page and then go back to my bank, I'm still logged in because of a cookie. Other users on the internet can hit the same URLs at my bank as I do, yet they won't be able to access my account without the cookie. If cross-origin requests are allowed, a malicious website can effectively impersonate the user.

– Brad

Suppose you have a common home router, such as a Linksys WRT54g or something. Suppose that router allows cross-origin requests. A script on my web page could make HTTP requests to common router IP addresses (like 192.168.1.1) and reconfigure your router to allow attacks. It can even use your router directly as a DDoS node. (Most routers have test pages which allow for pings or simple HTTP server checks. These can be abused en masse.)

– Brad

I feel that these comments should have been answers, because they explain the problem with a reallife example.

Answer 3

By responding with Access-Control-Allow-Origin: *, the requested resource allows sharing with every origin. This basically means that any site can send an XHR request to your site and access the server’s response which would not be the case if you hadn’t implemented this CORS response.

So any site can make a request to your site on behalf of their visitors and process its response. If you have something implemented like an authentication or authorization scheme that is based on something that is automatically provided by the browser (cookies, cookie-based sessions, etc.), the requests triggered by the third party sites will use them too.

This indeed poses a security risk, particularly if you allow resource sharing not just for selected resources but for every resource. In this context you should have a look at When is it safe to enable CORS?.