CORS Policy Reviewer

What this skill does

Audits a CORS configuration (Express middleware, NGINX directives, or a CDN policy) for known over-permissive patterns and proposes a tightened policy grounded in observed cross-origin call patterns from access logs.

Inputs

• config_path: file containing the CORS config (e.g., app.ts, nginx.conf, cdn-policy.json).
• access_log: a sample of request logs covering at least 7 days, with Origin headers preserved.
• Optional allowed_clients: explicit list of trusted client origins.

Steps

1. Parse the config and extract directives: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, Access-Control-Max-Age.
2. Detect smells:
   • Allow-Origin: * combined with Allow-Credentials: true is invalid per spec; flag as blocker.
   • Allow-Origin: * on endpoints that accept authenticated requests should be replaced with explicit origins.
   • Allow-Methods containing methods the server doesn't actually expose (e.g., OPTIONS, GET, POST, PUT, DELETE, PATCH when only GET is implemented).
   • Allow-Headers: * permits anything; replace with the actual set used.
3. From access_log, harvest observed values: distinct Origin values, distinct Access-Control-Request-Method, distinct Access-Control-Request-Headers.
4. Cross-reference observed origins against allowed_clients. Origins outside the allowlist with non-trivial traffic indicate either expected partner integrations or potential attack reconnaissance — surface both.
5. Build the tightened policy: an explicit origin list, the methods actually used, the headers actually requested, Allow-Credentials: true only on endpoints that need cookies.
6. For preflight optimization, set Max-Age to 600 if currently unset.
7. Render a config patch in the same syntax as the input file (Express middleware code or NGINX directives).
8. Emit a markdown report.

Output

cors-review.md containing: current config summary, smells with severity, observed-origin table, proposed tightened policy (paste-ready snippet), rollout checklist. Plus cors-tightened.<ext> for direct application.

Verification

Deploy the tightened policy in a staging environment and run a synthetic test: from each origin in the new allowlist, send a preflight (OPTIONS) and the actual request; confirm 2xx. From an origin NOT in the allowlist, confirm the browser blocks the response (the server may still echo permissive headers if proxied; verify at the browser layer). Watch error logs for 7 days; partner origins missed in the audit will surface as 4xx spikes.

Edge cases

• API gateways adding their own CORS layer: detect duplicate headers and recommend choosing one source of truth.
• Wildcard subdomains for the org's own apps (*.company.com): allow but require an explicit subdomain regex rather than a star.
• Origins on null (file:// or sandboxed iframes): generally should not be permitted; flag as suspicious.
• Browsers that don't send Origin on simple requests: the audit relies on logs; document blind spots and recommend application-layer logging of Sec-Fetch-Site.