191

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?

4
  • 5
    The answer stackoverflow.com/a/56457665/441757 from JaffaTheCake is the correct one: “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… cookies, HTTP basic auth, and TLS client certificates.” And see stackoverflow.com/a/43154277/441757 for more details. As long as you don’t include credentials in the request, Access-Control-Allow-Origin: * is safe. And if you do include credentials, browsers won’t allow you to do Access-Control-Allow-Origin: *. Safe.
    – sideshowbarker
    Sep 24, 2021 at 23:47
  • @sideshowbarker Sadly, I don't think it's that simple: security.stackexchange.com/questions/227779/…
    – jub0bs
    Nov 8, 2022 at 17:52
  • @sideshowbarker I would love to chat, but it's (past) bedtime for me, here. Maybe tomorrow morning :) But yes, I was referring to the typical practice of configuring a blanket ACAO: * policy at the reverse-proxy level, which would also cover sensitive endpoints like login.
    – jub0bs
    Nov 8, 2022 at 23:16
  • Some comments moved into chat.
    – sideshowbarker
    Nov 8, 2022 at 23:19

5 Answers 5

100

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.

9
  • 2
    If you can give a specific example of how the shared auth access poses a security risk, I'll upvote this. Apr 10, 2013 at 12:56
  • 1
    @Gumbo What about static content? (e.g. static cdn content, such as javascripts, css, static htmls etc.) Are there any security issues of setting Access-Control-Allow-Origin: * on them? There will be no nogin etc, they are public to everyone? Jun 27, 2013 at 7:14
  • 30
    Actually this answer is not quite correct according to the current CORS standard: "The string '*' cannot be used for a resource that supports credentials." So you cannot force a request to use transient authentication in the form of cookies, cached HTTP authentication or client SSL certificates. However if the website were for example to use local storage for authentication, that would be a problem.
    – Niklas B.
    Aug 25, 2014 at 23:29
  • 2
    @NiklasB: I tried this scenario and Chrome does follow the CORS standard as you have mentioned. i.e. the string "" is not supported with a credentials request. Here is what is reported by Chrome: "XMLHttpRequest cannot load localhost:12346/hello. A wildcard '' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'localhost:12345' is therefore not allowed access. The credentials mode of an XMLHttpRequest is controlled by the withCredentials attribute."
    – factotum
    Apr 19, 2016 at 14:55
  • 2
    This is definitely a security risk blog.portswigger.net/2016/10/… and youtube.com/watch?v=wgkj4ZgxI4c
    – dft
    Oct 12, 2017 at 18:23
77

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: *.

13
  • should "as it only allows requests without cookies" be "as it only allows requests with cookies"?
    – DJCordhose
    Jun 5, 2019 at 9:41
  • 4
    @DJCordhose no. Access-Control-Allow-Origin: * only allows requests without cookies. I've edited the answer to clarify a bit. Jun 5, 2019 at 9:45
  • What is the difference between "*" and case without this header at all. Is it the same?
    – Nigrimmist
    Sep 25, 2019 at 13:08
  • 5
    @SamRueby say you went to my evil page, I could call fetch('https://intranet.example.com/company-private-data'), which runs on your machine, and send the results back to my server. By doing this, I've used your access to the intranet to read the intranet. Sep 25, 2020 at 9:44
  • 1
    Surprised there's no shameless plug for youtu.be/vfAHa5GBLio?t=624
    – Max Coplan
    Feb 22, 2021 at 20:44
13

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.

11
  • 11
    Look at this from the point of view of an unwary end user. Someone can set up a malicious webpage which injects JavaScript to pass data between the real site and a malicious site (let's say they want to steal your password). The end user's web browser will normally block this cross site communication, but if the Access-Control-Allow-Origin is set, then it will be allowed, and the end user will be none the wiser.
    – Brain2000
    Apr 11, 2014 at 15:57
  • 5
    Yes, setting Access-Control-Allow-Origin * on a malicious website that hosts scripts to steal passwords is strongly discouraged :-)
    – commonpike
    Apr 12, 2014 at 18:24
  • 9
    @commonpike You are correct in that someone could make a script to just totally ignore the header. If the data is accessible, it's accessible with or without CORS headers. There's another attack vector you're not considering though. 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...
    – Brad
    Oct 31, 2016 at 0:08
  • 8
    @commonpike ... the user. Put another way, you might just visit my site (which could even be a normal site, with nothing suspicous... maybe it's a real legit site that was just hijacked!) but some JavaScript that makes HTTP requests to your bank to transfer some funds to my account. The bank doesn't know the difference between requests from its pages or requests from other pages. Both have that cookie enabling the request to succeed.
    – Brad
    Oct 31, 2016 at 0:10
  • 5
    @commonpike Let me give you a more common example... one that happens all the time. 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
    Oct 31, 2016 at 0:12
11

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.

5
  • 12
    Except this won't work. "The string '*' cannot be used for a resource that supports credentials." w3.org/TR/cors/#resource-requests
    – bayo
    Mar 31, 2017 at 12:36
  • @bayotop How does the browser distinguish between pages that require authentication and those with other data in the headers?
    – wedstrom
    Aug 8, 2017 at 16:12
  • After reading the provided link, there is "supports credentials flag" which is used for this purpose. It seems to be set manually, so presumably if someone didn't know how to set up CORS correctly they could get this flag wrong as well, so I believe the above vulnerabilities are possible.
    – wedstrom
    Aug 8, 2017 at 16:18
  • 4
    @wedstrom The flag is set by the one who makes the request. Anyway, the above scenarios are examples of CSRF attacks. Allowing the '*' origin won't make you more vulnerable then you already are (maybe a little bit in rare cases). In most cases you can make the malicous cross-site request using forms so CORS doesn't matter. In cases where you need to do an AJAX request, pre-flight requests will come in the way (this is the point where the browser comes in when ACAO: '*' and Access-Control-Allow-Credentials: 'true').
    – bayo
    Aug 9, 2017 at 14:30
  • Regarding example like those, can an extension like this one be dangerous? chrome.google.com/webstore/detail/allow-cors-access-control/… In fact I've used it in a small web application of mine, and I have security concerns.
    – carloswm85
    Dec 14, 2021 at 21:06
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.