Here's the short answer. When a certain set of conditions is met a wildcard CORS policy is pretty dangerous. However, in most scenarios, practical exploitation is difficult.

Scenario A: Drive-by Data Exfil

Scenario A is by far the most risky, however all of the following conditions need to be met for this to be exploitable:

1. Authentication Mechanism

• Your application uses cookies for authentication (or another mechanism that sends credentials automatically, such as HTTP Basic, Digest, or TLS).
  • The session cookie has the SameSite flag set to None, which allows it to be sent in cross-origin requests.

2. CORS Policy

• The Access-Control-Allow-Credentials header is set to true, which allows browsers to include credentials (e.g., cookies) in cross-origin requests.
• The Access-Control-Allow-Origin header reflects the request origin dynamically (effectively acting like a wildcard *).
  • e.g. In Express.js: this is achieved by setting the origin option to true.

Note: The standard doesn't actually permit Access-Control-Allow-Origin: * in combination with Access-Control-Allow-Credentials: True.

If your application meets these conditions, attackers can exploit it to steal data from your users without any interaction required. Here’s how.

Our user browses to malicious-site.com which includes some JavaScript. This JavaScript performs the following actions:

1. A cross-site request is made to your website to retrieve sensitive information.
   1. Because the session cookie has SameSite=None and the browser includes credentials in the request (due to Access-Control-Allow-Credentials: true), the request is authenticated.

2. Sensitive data (accessible by the victim) is returned to the browser on the malicious site.

3. This response is read and then sent to any attacker owned webserver for storage.
   1. Access-Control-Allow-Origin: malicious-site.com permits the JavaScript to actually read the response in 2.

The ability for Cookies to be included automatically is what makes this scenario dangerous, it lets attackers access authenticated functionality.

Fixes

1. Change the SameSite flag for your Cookie to Lax or Strict.
2. Do not permit a reflected arbitrary origin for Access-Control-Allow-Origin.
3. If not required, do not return Access-Control-Allow-Credentials: True.

If you'd like to see first hand what exploitation/fixing this looks like, we've built a small demo app you can try this against.

Without being able to use a victim's existing authenticated ssesion, this restricts potential exploitation to scenarios that abuse unauthenticated resources.

Scenario B: Internal Network Applications with No Auth

If an internal application assumes authentication is guaranteed solely by the user’s network location (e.g., being on a corporate VPN or LAN) and uses a permissive wildcard CORS policy (Access-Control-Allow-Origin: *), an attacker could coax a victim into visiting a malicious site. This site could then silently trigger requests to the internal application from the victim’s browser.

Because the wildcard CORS policy allows the attacker’s site to read responses, sensitive data from the internal application (intended only for trusted users on the network) could be leaked.

The main fix? 

Your internal applications should enforce authentication! Network location alone is not a secure substitute for verifying user identity.

Scenario C: Unauthenticated Abuse

This leaves us with some edge cases that an attacker may try to abuse for endpoints/resources intended to be exposed unauthenticated.

In no particular order, here are some scenarios that I've come up with.

1. Phishing

An attacker could build a malicious client app that mimics your legitimate service (a fake login portal and application).

The user would login and the attacker could embed calls to your API, to harvest user-specific data (like email addresses or internal IDs) from unsuspecting victims.

2. Bypassing Rate Limits/IP Based Restrictions

Endpoints that accept unauthenticated POST/PUT requests (e.g. voting & feedback forms, analytics trackers) could be flooded with forged data to corrupt datasets, skew metrics when user's simply browse to pages containing malicious JavaScript.

3. Resource Consumption

If your server hosts large, publicly accessible resources (e.g., media files, datasets, or APIs) and uses a permissive CORS policy (Access-Control-Allow-Origin: *), attackers can abuse this to offload their own hosting costs onto your infrastructure.