Validating CORS Policies
Overview
Validate Cross-Origin Resource Sharing configurations in web applications and APIs for security misconfigurations that enable unauthorized cross-origin access. This skill analyzes CORS headers, middleware configurations, and server response behavior to detect wildcard origins, reflected origins, credential leakage, and overly permissive header/method exposure.
Prerequisites
- Access to the target codebase and configuration files in
${CLAUDE_SKILL_DIR}/ - For live endpoint testing: WebFetch tool available and target URLs accessible
- Familiarity with the web framework in use (Express, Django, Flask, Spring, ASP.NET, etc.)
- Reference:
${CLAUDE_SKILL_DIR}/references/README.mdfor CORS specification details, common vulnerability patterns, and example policies
Instructions
- Locate all CORS configuration points by scanning for
Access-Control-Allow-Origin,cors()middleware,@CrossOriginannotations, CORS policy builders, and server config directives (nginxadd_header, ApacheHeader set) using Grep. - Check for wildcard origin (
Access-Control-Allow-Origin: *) -- flag as severity high when combined withAccess-Control-Allow-Credentials: true, which browsers reject but indicates a misunderstanding of the security model. - Detect origin reflection patterns where the server echoes back the
Originrequest header without validation -- search for code that reads theOriginheader and sets it directly in the response. Flag as CWE-942 (Permissive Cross-domain Policy), severity critical. - Validate the origin allowlist: check that allowed origins use exact string matching rather than substring or regex patterns vulnerable to bypass (e.g.,
example.com.evil.commatching a check forexample.com). - Assess
Access-Control-Allow-Methods-- flag if dangerous methods (PUT,DELETE,PATCH) are exposed without necessity. Verify that preflight (OPTIONS) responses include appropriate method restrictions. - Evaluate
Access-Control-Allow-Headers-- flag wildcard header allowance or exposure of sensitive headers likeAuthorization,Cookie, or custom auth headers to broader origins than necessary. - Check
Access-Control-Expose-Headersfor leakage of internal headers (e.g.,X-Request-Id,X-Internal-Trace) to cross-origin consumers. - Verify
Access-Control-Max-Ageis set to a reasonable value (600-86400 seconds) to balance security with performance -- missing or excessively long max-age values deserve a low-severity note. - For live endpoints, issue preflight requests via WebFetch with various
Originvalues (legitimate, malicious, null) and analyze the response headers to confirm server behavior matches the codebase configuration. - Compile findings with severity ratings, map to OWASP Testing Guide OTG-CLIENT-007, and provide remediation with correct CORS middleware configuration examples.
Output
- CORS configuration inventory: Table of all CORS-enabled endpoints, their allowed origins, methods, headers, and credentials settings
- Findings report: Each finding includes severity, affected endpoint/file, CWE reference (CWE-942, CWE-346), observed behavior, and remediation code
- Preflight test results: For live endpoints, a table of Origin values tested and the corresponding server responses
- Remediation examples: Framework-specific CORS configuration snippets (Express
cors(), Djangodjango-cors-headers, Spring@CrossOrigin, nginx headers)
Error Handling
| Error | Cause | Solution |
|---|---|---|
| No CORS configuration found | CORS handled at infrastructure layer (CDN, API gateway) | Check CDN/gateway configs (Cloudflare, AWS API Gateway, nginx) for CORS header injection |
| WebFetch blocked or timed out | Target endpoint unreachable or rate-limited | Verify URL accessibility; fall back to static codebase analysis of CORS middleware configuration |
| Inconsistent CORS behavior across endpoints | Multiple CORS configurations at different layers | Map each layer (application, reverse proxy, CDN) and document the effective policy per endpoint |
| Origin reflection false positive | Dynamic origin validation with a secure allowlist | Verify the allowlist logic uses exact matching; mark as informational if the implementation is secure |
| Preflight not triggering | Request classified as "simple request" by the browser | Note that simple GET/POST requests bypass preflight; test with custom headers to force preflight |
Examples
Express.js CORS Middleware Audit
Scan ${CLAUDE_SKILL_DIR}/src/app.js and ${CLAUDE_SKILL_DIR}/src/middleware/ for cors() configuration. Flag origin: true (reflects any origin) as CWE-942, severity critical. Recommend replacing with an explicit allowlist: origin: ['https://app.example.com', 'https://admin.example.com'].
Nginx CORS Header Review
Grep ${CLAUDE_SKILL_DIR}/nginx/ for add_header Access-Control-Allow-Origin. Flag any $http_origin variable usage that reflects the origin without validation. Verify that Access-Control-Allow-Credentials is only set for origins in the allowlist using an if block or map directive.
API Gateway CORS Configuration
Review ${CLAUDE_SKILL_DIR}/infra/api-gateway.yaml or equivalent IaC definitions for CORS settings. Flag wildcard * in allowed origins when credentials are enabled. Verify that Access-Control-Allow-Methods is scoped to only the HTTP methods each endpoint actually supports.