$devtoolkit.sh/examples/security/cors-headers

Parse CORS HTTP Response Headers

CORS misconfigurations are responsible for a large share of frontend API integration failures. These headers tell the browser which origins, methods, and request headers a server allows in cross-origin requests. The HTTP header parser decodes the values and explains each directive so you can diagnose blocked requests without guesswork. Check Access-Control-Allow-Credentials carefully — it requires an explicit origin (not a wildcard) to function correctly.

Example
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-Request-ID
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400
Vary: Origin
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
[ open in HTTP Header Parser → ]

FAQ

Why does CORS block requests with credentials when using a wildcard origin?
Browsers reject CORS responses that combine Access-Control-Allow-Credentials: true with Access-Control-Allow-Origin: * because allowing credentials to any origin would be a serious security risk.
What does Access-Control-Max-Age do?
It caches the preflight OPTIONS response for the specified number of seconds, reducing the overhead of preflight requests for complex CORS calls.
How do I debug a CORS error in the browser?
Open DevTools Network tab, find the failing request, and look at the response headers. The actual CORS headers (or their absence) tell you exactly what the server is or is not allowing.

Related Examples

/examples/security/cors-headersv1.0.0