Cors security

CORS Security

Rules (for AI agents)

ALWAYS

• Use an allowlist of origins, not *. Reflect the incoming Origin header only when it matches a known entry from configuration (or matches a precompiled regex of operator-controlled hostnames).
• If responses include credentials (cookies, Authorization), set Access-Control-Allow-Credentials: true and ensure Access-Control-Allow-Origin is a single specific origin string — never *.
• Include Vary: Origin on responses whose body depends on the request Origin, so caches don't serve one origin's response to another.
• Restrict preflight Access-Control-Allow-Methods to the actual methods the endpoint accepts; restrict Access-Control-Allow-Headers to the actual headers consumed.
• Set Access-Control-Max-Age to a sensible value (≤ 86400 in production) to amortize preflight latency without locking in a bad allowlist.
• Maintain the allowlist in code (or in a config file checked into source), not derived from a database — so attackers can't add their origin by inserting a row.

NEVER

• Set Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true. The Fetch spec forbids it for a reason — browsers will refuse the response, but the bigger problem is that an upstream proxy / cache may already have leaked it.
• Reflect the Origin header without an allowlist check (Access-Control- Allow-Origin: <Origin> for every incoming origin). That's the same as * for credentials but with worse caching behavior.
• Allow null as an Origin. null is what Chrome sends from sandboxed iframes, data: URIs, and file:// — none of which should have credentialed access to your API.
• Allow arbitrary subdomains with a regex like .*\.example\.com$ without considering subdomain takeover. Pin specific subdomains; treat *.example.com as a deliberate decision tied to subdomain ownership controls.
• Expose internal headers via Access-Control-Expose-Headers. Limit to the minimal set the frontend genuinely needs.
• Use CORS as authorization. CORS is a browser policy; it does not stop server-to-server, curl, or non-browser clients. Authenticate the request properly.

KNOWN FALSE POSITIVES

• Truly public, unauthenticated APIs (e.g., open data, marketing CDN endpoints) can legitimately use Access-Control-Allow-Origin: * without credentials.
• Internal admin tools restricted to a private network can use a single fixed origin; the wildcard concern doesn't apply because there are no cross-origin callers.
• A handful of integrations (Stripe.js, Plaid, Auth0) expect specific CORS headers — read each provider's CORS section before relaxing the baseline.

Context (for humans)

CORS is widely misunderstood as a security control. It isn't — it's a relaxation of the same-origin policy. The security control is authentication. CORS misconfiguration matters because, when combined with cookies or Authorization headers, it gives untrusted origins the ability to make credentialed cross-origin requests and read the response.

This skill is short by design — the matrix of bad combinations is finite and the rules are blunt.

Verify & lock (triaging a finding)

A scanner/review hit is a candidate, not a confirmed bug. Confirm it, fix it, then lock it so it can't come back.

1. Confirm it's real (probe the suspect input). Replay a request to the endpoint with a forged Origin header the allowlist should reject — Origin: https://evil.example, then separately Origin: null — and send credentials (cookie or Authorization). A real hit: the response echoes Access-Control-Allow-Origin: https://evil.example (or null, or *) together with Access-Control-Allow-Credentials: true, meaning the attacker's page can read the credentialed response. A false positive: the server omits the ACAO header, returns a fixed trusted origin regardless of input, or sends * with no credentials on a genuinely public endpoint — also watch for *.example.com regexes that match attacker-controlled subdomains, and missing Vary: Origin on cached responses.
2. Fix, then lock with a regression test (unit or integration — dev's call): assert that requests with Origin: https://evil.example and Origin: null yield no reflected ACAO (never * paired with Allow-Credentials: true), while a known-good origin from the allowlist is reflected as a single specific value with Vary: Origin present. Commit it to CI so the guard can't be silently dropped in a later refactor.

References

• rules/cors_safe_config.json
• OWASP CORS Origin Header Scrutiny.
• CWE-942.
• Fetch — CORS protocol.