---
name: cors-security
description: "Strict CORS configuration: no wildcard with credentials, allowlist-based origins, sensible preflight cache, minimal exposed headers — Applies to: when generating CORS middleware or framework config; when wiring API Gateway / Cloud Front / Nginx CORS headers; when reviewing a cross-origin browser-facing endpoint"
---

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/cors-security/SKILL.md. -->

# CORS Security

Strict CORS configuration: no wildcard with credentials, allowlist-based origins, sensible preflight cache, minimal exposed headers

## 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.