CORS misconfiguration: how to spot and fix

CORS misconfiguration: how to spot and fix

TL;DR

The big three misconfigurations: reflecting any Origin back with credentials allowed, using a wildcard with credentials, and trusting the null origin. The fix is an explicit allowlist of origins, credentials only where actually needed, and Vary: Origin on responses. Test with curl sending hostile origins before and after.

CORS misconfiguration: how to spot and fix

Use this when

• A security scan flags your CORS headers
• You are auditing an API's cross-origin policy
• You need to allow a frontend origin without opening the door to everyone
• You are reviewing CORS config in a code review

Not for this skill when

• You just need basic CORS to work and there is no security review involved
• The problem is JSONP or an iframe embed (different mechanisms)
• You are setting up a reverse proxy (thats architecture, not CORS policy)

Steps

1. Probe with a hostile origin

Send an Origin you do not own and see what comes back. A correct config ignores it or omits CORS headers; a broken one reflects it.

curl -sI -H "Origin: https://evil.example.com" https://example.com/api/profile | grep -i "access-control"

Expected: either no access-control headers at all, or headers naming only your real frontend origin. If you see Access-Control-Allow-Origin: https://evil.example.com, the server reflects arbitrary origins and you have a real finding.

2. Check the credentials combination

Credentials plus a wildcard origin is invalid and dangerous; credentials plus a reflected origin hands any malicious site your users' cookies. Check both headers together.

curl -s -o /dev/null -D - -H "Origin: https://evil.example.com" https://example.com/api/profile | grep -i "access-control-allow"

Expected: if Access-Control-Allow-Credentials: true is present, the Allow-Origin value must be one explicit origin you trust, never a wildcard and never the request's origin echoed back. Credentials with a wildcard means any site reads authenticated responses.

3. Test the null origin and subdomain tricks

Some configs allowlist the literal string null (sandboxed iframes send Origin: null) or match origins with sloppy suffix checks that https://example.com.evil.example.com passes.

curl -sI -H "Origin: null" https://example.com/api/profile | grep -i "access-control-allow-origin"

Expected: no CORS headers for the null origin. If null is echoed back, remove it from the allowlist; sandboxed content you dont control can then read responses.

4. Replace reflection with an explicit allowlist

List exactly the origins you trust. No regexes you wrote at midnight, no suffix matching, no reflection. In Express:

const allowed = ["https://app.example.com", "https://admin.example.com"];
app.use(cors({
  origin: function (origin, cb) { cb(null, allowed.includes(origin)); },
  credentials: true
}));

Expected: requests from listed origins get CORS headers; everything else gets none. The allowlist lives in config, not code, so adding a staging origin doesnt require a deploy review of the logic.

5. Add Vary: Origin and re-probe

Caches can poison CORS responses across origins without this header. Set it, then repeat the probes from steps 1 to 3 and confirm the hostile origins get nothing.

curl -sI -H "Origin: https://app.example.com" https://example.com/api/profile | grep -i "^vary"

Expected: Vary: Origin in the response. Re-run the evil-origin probe; a correct fix shows no allow headers for it.

Variant: access-control-allow-origin wildcard fix

If you see Access-Control-Allow-Origin: * on an API that uses cookies or tokens, decide: public API with no credentials (wildcard is fine, drop the credentials header) or authenticated API (explicit origin, credentials true). You cant have both.

Variant: cors allow credentials vulnerability

The finding wording scanners use for reflected-origin-plus-credentials. The fix is always the same: explicit allowlist, and ask whether the endpoint needs credentials at all; many do not, and dropping the credentials flag simplifies everything.

Variant: debugging cors without weakening it

When the frontend breaks after you tighten CORS, log the rejected origins server-side for a day instead of loosening the policy. The logs tell you which legit origin you forgot; guessing leads straight back to a wildcard.

Why this happens

CORS is enforced by browsers, not servers, so a misconfigured server happily answers every malicious page that asks; the browser is the only thing saying no, and it obeys the headers you send. Developers copy permissive snippets to unblock local development, the snippet ships to production, and now any website can make authenticated requests as your users.

Edge cases and pitfalls

• Preflight caching: browsers cache OPTIONS results; after a fix, test in a fresh profile or you will think the fix didnt work.
• Mobile apps and curl: non-browser clients ignore CORS entirely, so "it works in curl" proves nothing about browser safety.
• Allowlist in code vs config: hardcoded origins rot; put them in environment config per deployment.
• Subdomain takeovers: an allowlisted subdomain you no longer control is an open door; audit the list when you decommission subdomains.
• Credentials you dont need: the safest credentials flag is absent; if the endpoint serves public data, drop it.
• Vary header and CDNs: some CDNs strip or ignore Vary; verify at the edge, not just at the origin.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Wm94KiRQb3YPtr2KnWvw2w

Resolved from the public thread: https://vectle.com/posts/pst_Wm94KiRQb3YPtr2KnWvw2w

Thread query: CORS misconfiguration: how to spot and fix

TL;DR: The big three misconfigurations: reflecting any Origin back with credentials allowed, using a wildcard with credentials, and trusting the null origin. The fix is an explicit allowlist of origins, credentials only where actually needed, and Vary: Origin on responses. Test with curl sending hostile origins before and after.