What is CORS Misconfiguration?

Cross-Origin Resource Sharing, specified as part of the WHATWG Fetch standard, is a controlled relaxation of the same-origin policy. By default, script on evil.example may send a request to api.example.com but cannot read the response. CORS lets the server opt in, using response headers to declare which origins are allowed to read what. A misconfiguration is when that opt-in is broader than intended, and the browser dutifully enforces the permissive policy the server asked for.

The headers involved

• Access-Control-Allow-Origin — which origin may read the response. A single origin, or *.
• Access-Control-Allow-Credentials: true — permits the request to carry cookies and for the response to be readable with them.
• Access-Control-Allow-Methods / Allow-Headers — what a preflight OPTIONS request authorises.
• Access-Control-Expose-Headers — which response headers script may read.

The dangerous patterns

Reflecting the request origin with credentials. The wildcard * cannot legally be combined with Allow-Credentials: true, so developers who need credentialed cross-origin access often echo whatever Origin header arrived. The result is that every origin is allowed, including an attacker’s — and with cookies attached, so any authenticated data the endpoint returns can be read from a malicious page a victim happens to visit.

Sloppy origin matching. Validating with a suffix or substring check rather than an exact comparison. https://example.com.evil.net ends the test happily if the code only asks whether the origin contains example.com.

Trusting null. Sandboxed iframes and some local contexts send Origin: null; allowing it with credentials hands access to any page that can create such a frame.

Allowing internal or forgotten origins. Staging, development and partner origins left in an allowlist are only as trustworthy as those hosts, which are often the weakest in the estate and prone to subdomain takeover. A permissive policy that trusts *.example.com becomes exploitable the moment any subdomain is compromised or an XSS exists on one.

Getting it right

Maintain an explicit allowlist and compare origins exactly. Never enable credentials unless cross-origin authenticated access is genuinely required, and keep those endpoints as narrow as possible. Remember that CORS controls reading, not sending — it is not a substitute for CSRF protection, and a permissive policy does not make a request safe to process. Endpoints discovered through API endpoint discovery and GraphQL introspection are worth checking specifically, since API hosts are where credentialed CORS tends to be configured.

Related concepts

See CSP, cross-site scripting, security misconfiguration, least privilege and OWASP Top Ten.