How do I exploit an application returning headers as the following

Access-Control-Allow-Origin: *

What exact information do we get if the following is set to *

To make it concise, If an application has an authenticated page with the Access-Control-Allow-Origin set to *, is the information accessible without authentication.

  • I consider this question as too broad. Setting the CORS policy too broad can result in a variety of problems but exact exploits depend on the exact applications. I recommend you simply search for exploit cors wildcard to get a feeling on what can be done and how. If you have then more specific questions feel free to ask again. May 6, 2018 at 18:14
  • I have simplified the question with more precise questioning as which exact scenario am I referring to @SteffenUllrich May 7, 2018 at 7:20
  • CORS has nothing to do with requiring authentication. Authentication is checked by the server, CORS policy is checked by the client. But, a too permissive CORS policy can result in a cross-site request which enables an attacker to read external resources if the browser is already authenticated to access these external resources. May 7, 2018 at 8:25

2 Answers 2


The Access-Control-Allow-Origin response header indicates whether the response can be shared with resources with the given origin.

(From MDN)

When the server sends Access-Control-Allow-Origin: *, it allows any origin to access the resource in a cross-origin request. But the extent to which this is exploitable varies.

Let's say, you're logged in for online banking at https://yourbank.example/ and the site sets the ACAO header. At the same time, you're visiting an attacker-controlled site in another tab. Now, the attacker's site could load a script which issues a cross-origin request to your online banking dashboard in the background, along the lines of:

fetch('https://yourbank.example/').then(r => r.text()).then(console.log)

In that case your browser would reveal your view of https://yourbank.example/ to the attacker. However, this isn't helpful, because your browser doesn't include authentication details (i.e., the session cookies) in the request by default. So all the attacker gets is your unauthenticated view of your bank's website.

Even if the site also sends Access-Control-Allow-Credentials: true (where the attacker can usually call fetch() with {credentials: 'include'} to read the response of an authenticated cross-origin request) you're out of luck because allow-credentials has no effect when ACAO is set to wildcard (*).

So, with ACAO: * alone, you're left with less likely attack scenarios. For example, it would work on an intranet site or router interface which displays confidential information even without authentication but isn't directly accessible to the attacker. (In that case it may also be vulnerable to DNS rebinding.)

  • The OP asked how to exploit this and I don't see any exploit here. CORS is not an access restriction enforced on the server side but only a restriction on the client side. This means an attacker could use curl or similar (which don't care about CORS) to access the resource. The part missing in this answer is IMHO that existing cookies will be sent together with the request (if withCredentials=true) and that the attacker could thus get read access to resources on a site where the user is currently logged in. May 6, 2018 at 20:16
  • @SteffenUllrich Regarding CORS being client side - I think that's sort of implied. But I agree I should lay out an actual exploit scenario and address nuances such as that cookies aren't sent without Access-Control-Allow-Credentials: true. I'm going to rewrite that.
    – Arminius
    May 6, 2018 at 21:00
  • So, 'Access-Control-Allow-Credentials: true' is fundamental for at least exploiting CORS. May 7, 2018 at 7:26

Sending Access-Control-Allow-Origin: * doesn't mean that the endpoint is generally exploitable. This might be perfectly fine e.g. for a public API endpoint which is designed to be accessed by anyone.

It would however be exploitable if the endpoint returns context sensitive data based on a user context generated by session cookies. In this case, a malicious website could request data from the endpoint in the context of a user and leak personal data or send data to the endpoint and impersonate the user.

Not the answer you're looking for? Browse other questions tagged .