What security risks exist when setting Access-Control-Allow-Origin to accept all domains?

I recently had to set Access-Control-Allow-Origin to * in order to be able to make cross-subdomain AJAX calls. I feel like this might be a security problem. What risks am I exposing myself to if I keep the setting?

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

Update (2020-10-07)

Current Fetch Standard omits the credentials when credentials mode is set to include, if Access-Control-Allow-Origin is set to *.

Therefore, if you are using a cookie-based authentication, your credentials will not be sent on the request.

Access-Control-Allow-Origin: * is totally safe to add to any resource, unless that resource contains private data protected by something other than standard credentials. Standard credentials are cookies, HTTP basic auth, and TLS client certificates.

Eg: Data protected by cookies is safe

Imagine https://example.com/users-private-data, which may expose private data depending on the user's logged in state. This state uses a session cookie. It's safe to add Access-Control-Allow-Origin: * to this resource, as this header only allows access to the response if the request is made without cookies, and cookies are required to get the private data. As a result, no private data is leaked.

Eg: Data protected by location / ip / internal network is not safe (unfortunately common with intranets and home appliances):

Imagine https://intranet.example.com/company-private-data, which exposes private company data, but this can only be accessed if you're on the company's wifi network. It's not safe to add Access-Control-Allow-Origin: * to this resource, as it's protected using something other than standard credentials. Otherwise, a bad script could use you as a tunnel to the intranet.

Rule of thumb

Imagine what a user would see if they accessed the resource in an incognito window. If you're happy with everyone seeing this content (including the source code the browser received), it's safe to add Access-Control-Allow-Origin: *.

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 https://stackoverflow.com/questions/14979313/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.

Here are 2 examples posted as comments, when a wildcard is really 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 real life example.

This answer was originally written as a reply to What are the security implications of setting Access-Control-Allow-Headers: *, if any? and was merged despite being irrelevant to this question.

---

To set it to a wildcard *, means to allow all headers apart from safelisted ones, and remove restrictions that keeps them safe.

These are the restrictions for the 4 safelisted headers to be considered safe:

> - For Accept-Language and Content-Language: can only have values consisting of 0-9, A-Z, a-z, space or *,-.;=. > - For Accept and Content-Type: can't contain a CORS-unsafe request header byte: 0x00-0x1F (except for 0x09 (HT), which is allowed), "():<>?@[\]{}, and 0x7F (DEL). > - For Content-Type: needs to have a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain. > - For any header: the value’s length can't be greater than 128.

For simplicity's sake, I'll base my answer on these headers.

Depending on server implementation, simply removing these limitations can be very dangerous (to the user).
For example, this outdated wordpress plugin has a reflected XSS vulnerability where the value of Accept-Language was parsed and rendered on the page as-is, causing script execution on the user's browser should a malicious payload be included in the value.

With the wildcard header Access-Control-Allow-Headers: *, a third party site redirecting to your site could set the value of the header to Accept Language: <script src="https://example.com/malicious-script.js"></script>, given that the wildcard removes the restriction in Point 1 above.

The preflight response would then give the greenlight to this request, and the user will be redirected to your site, triggering an XSS on their browser, which impact can range from an annoying popup to losing control of their account through cookie hijacking.

Thus, I would strongly recommend against setting a wildcard unless it is for an API endpoint where nothing is being rendered on the page.

You can set Access-Control-Allow-Headers: Pragma as an alternative solution to your problem.

---

Note that the value * only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information), otherwise it will be read as a literal header. Documentation

In scenario where server attempts to disable the CORS completely by setting below headers.

• Access-Control-Allow-Origin: * (tells the browser that server accepts cross site requests from any ORIGIN)

• Access-Control-Allow-Credentials: true (tells the browser that cross site requests can send cookies)

There is a fail safe implemented in browsers that will result in below error

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

So in most scenarios setting ‘Access-Control-Allow-Origin’ to * will not be a problem. However to secure against attacks, the server can maintain a list of allowed origins and whenever server gets a cross origin request, it can validate the ORIGIN header against the list of allowed origins and then echo back the same in Access-Control-Allow-Origin header.

Since ORIGIN header can't be changed by javascript running on the browser, the malicious site will not be able to spoof it.