What is a CORS misconfiguration?
Cross-Origin Resource Sharing controls which browser origins may read a server response. A misconfiguration occurs when the server trusts origins too broadly, reflects arbitrary Origin values, or combines permissive access with credentials.
CORS is enforced by browsers; it is not authentication. APIs must still validate sessions, authorization, request methods, and resource ownership on the server.
Why is reflected Origin dangerous?
Some applications copy the incoming Origin header into Access-Control-Allow-Origin without checking it against an allowlist. An attacker can host a page on another domain, send a request from a victim’s browser, and receive permission to read the response.
Impact depends on the endpoint and credential rules. Public, non-sensitive resources may intentionally allow broad access, while account, billing, or administrative APIs require narrowly defined origins.
How should CORS be configured?
Keep an explicit allowlist of trusted origins and compare complete origins, including scheme and port. Do not use substring matches such as endsWith on attacker-controlled hostnames, and do not blindly reflect request headers.
Return CORS headers only when the origin is approved. Limit methods and request headers to those the client needs, use credentials only where necessary, and add Vary: Origin when responses differ by requesting origin.
Frequently asked questions
Is Access-Control-Allow-Origin: * always unsafe?
No. It can be appropriate for intentionally public resources, but it should not expose sensitive personalized data.
Can wildcard CORS be used with credentials?
Browsers reject the literal wildcard with credentialed requests. Reflecting arbitrary origins while allowing credentials creates the more dangerous pattern.
Does CORS stop CSRF?
Not by itself. Use SameSite cookies, CSRF tokens, origin validation, and server-side authorization as appropriate.