I have done some research but have not found an absolute answer to my specific question. I understand the basic concept of how this header will allow or disallow website A from sending request and viewing response to resources on website B.

However, suppose website B set the header Access-Control-Allow-Credentials to false, and Access-Control-Allow-Origin: *, can this cause any concrete security risk to the user who is browsing website A (suppose website A is malicious)?

  • If website B uses authentication that ACAC doesn't understand, such as source IP address, that's vulnerable - but this will be rare. Security advice generally implies ACAO is dangerous, but I can't think of a concrete example of a weakness, and I reckon probably no impact. Interesting question, thanks
    – paj28
    Commented Mar 26, 2020 at 2:34
  • security.stackexchange.com/questions/127966/…
    – paj28
    Commented Mar 26, 2020 at 2:54
  • @paj28, I've seen the example following the link in the link you've provided, and yes I think the scenario is very specific, and the decision to solely based on IP for access-control is not safe by itself.
    – SamTest
    Commented Mar 26, 2020 at 3:28
  • 1
    Just a reminder: Access-Control-Allow-Origin: * implies Access-Control-Allow-Credentials: false, and ignores any actual Access-Control-Allow-Credentials header that is returned. Actually returning ACAC is pointless - it's required to be ignored - if you return ACAO: *.
    – CBHacking
    Commented Aug 28, 2021 at 9:13
  • Does this answer your question? Why is the Access-Control-Allow-Origin header necessary?
    – Ajedi32
    Commented Sep 7, 2021 at 21:29

1 Answer 1


[S]uppose website B set the header Access-Control-Allow-Credentials to false, and Access-Control-Allow-Origin: *, can this cause any concrete security risk to the user who is browsing website A (suppose website A is malicious)?

The answer is very context-dependent, but by indiscriminately using Access-Control-Allow-Origin: *, you may expose yourself to some types of attacks. I cover two of them below:

  1. Server bound to an inaccessible network interface
  2. Distributed client-side brute-force attack against login

Server bound to an inaccessible network interface

In particular, consider a situation in which site B is accessible by an unauthenticated victim only from a privileged position within the target network (e.g. behind a network firewall). In such cases,

  • because no ambient authority (like cookies) is involved, the presence or value of the Access-Control-Allow-Credentials header is irrelevant; and
  • the attacker, by tunnelling through to site B via the victim's browser when she visits site A, can read site B's responses from site A.

A real-life example

A few years ago, a similar vulnerability affecting multiple JetBrains IDEs was disclosed. Those IDEs would start a server bound to localhost with an excessively permissive CORS policy, which allowed an external attacker to exfiltrate sensitive data. The server in question reflected arbitrary origins in Access-Control-Allow-Origin (as opposed to using a wildcard *) but the distinction is irrelevant, in this case.

Some resources

  • The OWASP testing guide mentions this risk:

    Although [Access-Control-Allow-Origin: *] cannot be used with the Access-Control-Allow-Credentials: true at the same time, it can be dangerous where the access control is done solely by the firewall rules or the source IP addresses, other than being protected by credentials.

  • James Kettle (a.k.a. albinowax from PortSwigger), in his AppSec EU 2017 talk about CORS misconfiguration, further discusses CORS misconfigurations that do not involve credentials.

  • See also James's thoughts on the topic in written form:

    Without [Access-Control-Allow-Credentials: true], the victim user's browser will refuse to send their cookies, meaning the attacker will only gain access to unauthenticated content, which they could just as easily access by browsing directly to the target website. However, there is one common situation where an attacker can't access a website directly: when it's part of an organization's intranet, and located within private IP address space. Internal websites are often held to a lower security standard than external sites, enabling attackers to find vulnerabilities and gain further access. [...] If users within the private IP address space access the public internet then a CORS-based attack can be performed from the external site that uses the victim's browser as a proxy for accessing intranet resources.

  • Private Network Access is a WICG specification whose goal is to protect against attacks issued from "less private" networks (e.g. a server accessible at example.com) against a "more local" target (e.g. a server running on localhost). It's already partially implemented in Chromium.

Distributed client-side brute-force attack against login

Returning Access-Control-Allow-Origin: * on an authentication endpoint that's vulnerable to login CSRF (a vulnerability often dismissed as negligible) is dangerous. A malicious page could forge a login request and observe the result (success or failure) via JavaScript.

An attacker could even mount a distributed client-side brute-force attack against login by deploying a command-and-control server that would feed different candidate credentials to different victims (who happen to land on the malicious page). Such a distributed attack could prove difficult to thwart because IP-based or fingerprint-based protection (e.g. rate limiting) wouldn't be viable. Tim Tomes and Kevin Cody described such an attack in their DerbyCon 2019 talk.

  • 1
    Yes, authorization by network position (server bound only to loopback, incoming IP filter, requiring IPsec, etc.) is the only place I can think of where this matters, but it does matter there.
    – CBHacking
    Commented Aug 28, 2021 at 9:11
  • @CBHacking See my edit.
    – jub0bs
    Commented Oct 23, 2021 at 11:07
  • 1
    Oh nice, already upvoted but I'd do it again; the distributed brute-force attack on login is a neat example and I missed that DerbyCon talk.
    – CBHacking
    Commented Oct 23, 2021 at 22:32
  • @CBHacking No problem. I'll keep editing my answer as I find more attack scenarios.
    – jub0bs
    Commented Oct 24, 2021 at 9:50

You must log in to answer this question.

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