CORS Misconfiguration Evaluator
Simulate cross-origin preflight checks (OPTIONS) and audit your API response headers. Automatically detect fatal credential leaks, unchecked dynamic origin reflections, and trusted 'null' origin exploits.
CORS Request & Response Parameters
Simulate API preflightsResource access is restricted to a declared cryptographic HTTPS origin.
Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Headers: Authorization, Content-Type Access-Control-Max-Age: 7200
Reserved banner container configured with strict Core Web Vitals CLS = 0 layout preservation.
The Same-Origin Policy (SOP) and Why CORS Exists
The fundamental security boundary of the World Wide Web is the Same-Origin Policy (SOP), formalized in RFC 6454. Under SOP, a web application running in a user's browser is strictly prohibited from reading data from another origin (a different combination of protocol, hostname, or port number).
Cross-Origin Resource Sharing (CORS) is a relaxation mechanism that allows servers to selectively declare which external origins are authorized to bypass SOP. However, because developers frequently struggle with blocked frontend requests, they often resort to copy-pasting insecure boilerplate configurations that completely compromise user session privacy.
The 3 Most Dangerous CORS Vulnerabilities in Production
Specifying Access-Control-Allow-Origin: * alongside Access-Control-Allow-Credentials: true. Browsers strictly reject this combination by specification, causing frontend requests to break completely.
To bypass the wildcard credential restriction, some servers naively copy the incoming Origin header directly into Access-Control-Allow-Origin. This grants any malicious website on the internet full read access to authenticated user accounts.
Whitelisting Access-Control-Allow-Origin: null allows sandboxed iframes (<iframe sandbox="allow-scripts">) or local HTML exploits to bypass same-origin protections.
Comparative Security Matrix: Safe vs. Vulnerable CORS
| Scenario | Allow-Origin | Allow-Credentials | Risk Assessment |
|---|---|---|---|
| Public API (Unauthenticated) | * | false (or omitted) | Safe (Public Open Data) |
| Authenticated Web App | https://app.example.com | true | Safe (Strict Domain Whitelist) |
| Broken Attempt | * | true | Critical Error (Blocked by browser) |
| Dynamic Reflection | req.headers.origin | true | Critical Vulnerability (Total data leak) |
Hardened CORS Implementation: How to Whitelist Safely
Instead of reflecting every origin, validate incoming origins against an explicit array of trusted domains:
app.use(cors({
origin: (origin, callback) => {
if (!origin || allowed.includes(origin)) {
callback(null, true);
} else {
callback(new Error('Blocked by CORS'));
}
},
credentials: true
}));
"https://app.example.com" $http_origin;
"https://admin.example.com" $http_origin;
default "";
}
add_header Access-Control-Allow-Origin $cors_origin always;
add_header Access-Control-Allow-Credentials "true" always;
Frequently Asked Questions
No! CORS is strictly a browser-enforced policy. Non-browser clients (like curl, Postman, Python scripts, or attack bots) do not respect CORS headers and can send requests freely. CORS only prevents malicious websites from reading API responses via a user's browser.
A preflight request is triggered if an HTTP request uses methods other than GET, POST, or HEAD, sends custom headers (such as Authorization), or uses a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain.
It tells the browser how many seconds it can cache the results of a preflight OPTIONS request before sending another one. Setting it to 7200 (2 hours) reduces latency and server load for repeated API requests.
By default, browsers only expose simple response headers (like Cache-Control, Content-Type) to JavaScript. To let your frontend read custom headers (like X-Total-Count or X-RateLimit-Remaining), you must list them in Expose-Headers.