CORS Policy Inspector
Analyze CORS headers for misconfigurations including wildcard origins, dangerous credential combinations, and overly permissive methods
Enter CORS response headers in "Header-Name: value" format, one per line
Inspecting CORS Policies for Security Misconfigurations
Cross-Origin Resource Sharing (CORS) is the browser mechanism that controls which external domains can make requests to your API. A properly configured CORS policy protects sensitive endpoints from unauthorized cross-origin access while allowing legitimate frontend applications to communicate with your backend. Misconfigurations — wildcard origins combined with credentials, overly permissive method lists, or exposing sensitive response headers — create attack surfaces that enable credential theft, data exfiltration, and cross-site request forgery.
The CORS Policy Inspector analyzes your Access-Control headers to detect dangerous configurations, overly permissive allowances, and common mistakes that weaken your API's security posture. Each finding explains the specific risk, provides the current misconfigured value, and recommends a secure alternative. All analysis happens entirely in your browser.
Dangerous Wildcard and Credential Combinations
The most critical CORS misconfiguration is combining wildcard origins with credential support:
-
Access-Control-Allow-Origin: *with credentials: Browsers block this combination, but servers that dynamically reflect the Origin header while also sendingAccess-Control-Allow-Credentials: trueeffectively create the same vulnerability. - Origin reflection: Servers that echo back any Origin header as the Allow-Origin value — this passes browser CORS checks but allows any website to make authenticated requests to your API.
-
Null origin allowance: Allowing
Origin: null(sent by sandboxed iframes and redirected requests) while supporting credentials enables attacks from contexts that should be untrusted.
The inspector detects these patterns and recommends explicit origin allowlists that enumerate only the domains that legitimately need cross-origin access to your API.
Method and Header Exposure Risks
CORS policies control which HTTP methods and response headers are accessible cross-origin:
-
Overly permissive methods: Allowing
DELETE,PATCH, or custom methods when onlyGETandPOSTare needed expands the attack surface unnecessarily. -
Sensitive exposed headers:
Access-Control-Expose-Headerslisting headers likeAuthorization,Set-Cookie, or custom session identifiers makes them readable by cross-origin JavaScript. -
Long preflight cache:
Access-Control-Max-Agevalues exceeding 86400 seconds mean CORS policy changes take over 24 hours to propagate to clients.
The principle of least privilege applies: only allow the methods, headers, and origins that your application actually requires for legitimate cross-origin communication.
Preflight Requests and Performance
Non-simple CORS requests trigger preflight OPTIONS requests that add latency. Understanding what triggers preflight helps optimize performance:
- Custom headers: Any header beyond Accept, Content-Type (with simple values), and Accept-Language triggers preflight
- Non-simple methods: PUT, DELETE, PATCH all require preflight
- Content-Type beyond simple:
application/jsontriggers preflight (only form-encoded and multipart are "simple")
The inspector identifies configurations where the preflight cache (Access-Control-Max-Age)
is missing or too short, causing unnecessary OPTIONS requests that double the latency of every
cross-origin API call.
Code Examples
CORS Headers Analysis Example
# Headers to analyze:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Headers: *
Access-Control-Expose-Headers: Authorization, X-Session-ID
Access-Control-Max-Age: 604800
# Inspector findings:
# - CRITICAL: Wildcard origin with credentials — browsers block this but
# the server intent suggests origin reflection may be happening
# - HIGH: Exposing Authorization header cross-origin enables token theft
# - WARN: All methods allowed — restrict to actually needed methods
# - WARN: Wildcard allowed headers — specify exactly which headers are needed
# - INFO: Max-Age 7 days — CORS policy changes will be slow to propagateStandards & Specifications
- Fetch Living Standard — CORS Protocol — Defines the CORS protocol behavior including preflight, credentials, and header handling
Frequently Asked Questions
What CORS headers does this tool analyze?
The CORS Policy Inspector analyzes Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Expose-Headers, and Access-Control-Max-Age. It detects misconfigurations, overly permissive settings, and dangerous header combinations.
Why is wildcard origin with credentials a critical issue?
The CORS specification explicitly forbids combining Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. Browsers will block such responses. However, finding this combination in your headers indicates a severe misconfiguration that could expose your API to credential theft if the browser enforcement were ever bypassed.
How is the security score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues (wildcard + credentials) deduct 25 points, High issues (null origin, sensitive exposed headers) deduct 15, Medium issues (wildcard origin, dangerous methods) deduct 8, and Low issues (excessive max-age, credentials enabled) deduct 3. The final score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
What format should the input be?
Enter CORS response headers in the standard "Header-Name: value" format, one per line. You can paste the full response headers from browser DevTools (Network tab → Response Headers) or just the Access-Control-* headers. HTTP status lines are automatically skipped.
Is my data sent to a server?
No. All analysis happens entirely in your browser using JavaScript. Your CORS headers are never transmitted to any server. No data is stored, logged, or shared.
What is the danger of Access-Control-Allow-Origin: null?
The null origin is used by sandboxed iframes, local file:// pages, and data: URLs. Trusting the null origin allows these contexts to make credentialed requests to your API, potentially leading to data theft. Never whitelist the null origin.
Why are PUT, DELETE, and PATCH flagged as dangerous methods?
These methods allow modifying or deleting server-side resources. Exposing them via CORS means any allowed origin can perform state-changing operations. Only expose methods that are actually required by your cross-origin clients, and always combine with proper authentication.
What is the difference between this tool and the Security Headers Analyzer?
The Security Headers Analyzer checks all HTTP security headers (HSTS, CSP, X-Frame-Options, etc.) at a high level. The CORS Policy Inspector performs deep analysis specifically of Access-Control-* headers, detecting dangerous combinations and evaluating each CORS directive individually.
What is Access-Control-Max-Age and why does a long value matter?
Access-Control-Max-Age tells browsers how long to cache preflight (OPTIONS) responses. A very long cache duration (over 24 hours) means that if you change your CORS policy, clients will not see the update until their cache expires. Keep it at 3600 (1 hour) or 86400 (24 hours) maximum.