CORS misconfiguration: when "Access-Control-Allow-Origin: *" is dangerous
A wide-open CORS policy can let any website read authenticated responses from your API. Here is when a wildcard is fine and when it leaks data.
CORS controls which other websites' JavaScript may read responses from your API. AI builders often set it wide open to "make the error go away," which can expose authenticated data.
When a wildcard is fine — and when it isn't
Access-Control-Allow-Origin: * is acceptable for public, unauthenticated endpoints. It becomes dangerous when combined with credentials: if you reflect the request's Origin (or send *) and set Access-Control-Allow-Credentials: true, any malicious site can make a logged-in user's browser fetch their private data and read it.
The fix
- Never combine a wildcard / reflected origin with
Allow-Credentials: true. - Maintain an explicit allowlist of origins you trust and echo back only those.
- For public read-only data with no cookies, a plain
*without credentials is fine.
FAQ
Is Access-Control-Allow-Origin: * always bad?
No. It is fine for public, unauthenticated endpoints. It is dangerous when paired with Access-Control-Allow-Credentials: true, which lets other sites read logged-in users’ responses.
How should I configure CORS for an app with logins?
Use an explicit allowlist of trusted origins and reflect only those. Do not send a wildcard or blindly reflect the Origin header when credentials are allowed.
Related questions
- Exposed source maps: your original source code is downloadable
- Unvalidated postMessage: a cross-window message handler without an origin check
- Subdomain takeover: a dangling DNS record an attacker can claim
- Debug artifacts, risky TODOs, and leaked AI prompts in your build