CORS Explained: When * Becomes a Vulnerability
What CORS actually protects, what it never protected, and the wildcard-plus-credentials misconfig that turns a header into an open door.
Short answer
CORS is a browser rule about which frontends may read API responses. It is not authentication. Access-Control-Allow-Origin: * is fine for public non-credentialed APIs and dangerous when paired with credentials or private data.
What CORS is and is not
It governs browser cross-origin reads. curl and server-side callers ignore it.
If you rely on CORS to protect private data, you already lost - any non-browser client walks around it.
Readers skimming cors explained misconfiguration often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Classic misconfig
Reflecting Origin with Allow-Credentials true without a strict allowlist turns every evil.com page into a logged-in reader of your API.
That bug class still ships regularly because "it worked in dev with localhost."
Common failure mode for cors explained misconfiguration: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Safe patterns
Public assets can use *. Private APIs need explicit origins, credentials only when required, and real auth on every sensitive route.
Test with a hostile origin page, not only your own frontend.
If this section on cors explained misconfiguration becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- List APIs that set Access-Control-Allow-Origin.
- If credentials are true, require an explicit origin allowlist.
- Confirm auth on sensitive routes independent of CORS.
- Test from a foreign origin page and document the result.
CORS is not a lock. Auth is a lock.
Update log (1)
2026-05-11Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
