</>
ProtocolCodes

CORS Checker

Check CORS (Cross-Origin Resource Sharing) headers for any URL. Verify allowed origins, methods, headers, and credentials support.

How to Use

  1. 1
    Enter the URL to check

    Provide the API endpoint or resource URL you want to test. Optionally specify the Origin header value (e.g., https://yourapp.com) to simulate a cross-origin request from a specific domain.

  2. 2
    Review the CORS headers

    Inspect Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, and Access-Control-Max-Age in the server response. Each header is explained with its RFC reference.

  3. 3
    Diagnose blocked cross-origin requests

    The checker identifies common misconfigurations: wildcard origin with credentials, missing preflight support for custom headers, and incorrect Vary header that breaks CDN caching of CORS responses.

About

Cross-Origin Resource Sharing (CORS) is the W3C mechanism that allows web applications running on one origin to access resources on a different origin in a controlled, opt-in fashion. Without CORS, the browser's Same-Origin Policy (enforced since Netscape Navigator 2.0) would block all cross-origin Ajax requests by default — a critical security boundary that prevents malicious pages from silently accessing authenticated APIs using a user's session credentials. CORS extends this model with server-declared policies encoded in response headers.

The CORS Checker performs both a simple GET request and a simulated preflight OPTIONS request against the target URL, capturing the full set of CORS response headers and evaluating them against the Fetch Living Standard. Misconfigurations detected include: returning Access-Control-Allow-Origin: * on endpoints that process cookies or Authorization headers, failing to handle OPTIONS preflight requests (causing all non-simple requests to fail silently), and omitting Vary: Origin which causes CDNs to cache CORS headers from one origin and serve them incorrectly to other origins.

For API developers, CORS configuration is often the last thing tested and the first thing that breaks in staging environments. The checker helps distinguish browser-enforced CORS failures from actual server errors, identifies which specific header is missing or misconfigured, and provides the exact header values needed to resolve the issue. It also flags the security risk of overly permissive CORS policies — such as reflecting any Origin back as Access-Control-Allow-Origin — which can undermine the entire purpose of the Same-Origin Policy.

FAQ

Why does my API work in Postman but fail in the browser with a CORS error?
CORS (Cross-Origin Resource Sharing, W3C Fetch Living Standard) is enforced exclusively by browsers as a security mechanism — it prevents malicious websites from making credentialed requests to APIs using your session cookies. Postman and curl are not browsers and do not enforce CORS. The CORS checker simulates what a browser would receive, showing whether the server sends the correct Access-Control-Allow-Origin header. The actual restriction happens in the browser's fetch/XHR engine, not the server.
What is a CORS preflight request and when is it triggered?
A preflight is an OPTIONS request sent automatically by the browser before the actual request when the request uses a non-simple method (anything other than GET/POST/HEAD), a non-simple Content-Type (anything other than application/x-www-form-urlencoded, multipart/form-data, or text/plain), or any custom header. The server must respond to OPTIONS with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers or the browser blocks the actual request. Access-Control-Max-Age caches the preflight result to reduce overhead.
Can I use Access-Control-Allow-Origin: * with credentials?
No. The Fetch Living Standard explicitly prohibits combining Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. When credentials (cookies, HTTP authentication, or client TLS certificates) are included in a cross-origin request, the server must reflect the exact requesting origin in Access-Control-Allow-Origin (e.g., Access-Control-Allow-Origin: https://app.example.com) and set Vary: Origin to ensure CDNs and proxies do not serve one user's credentialed response to another.
How does CORS interact with CDNs and caches?
CORS responses must include Vary: Origin when the Access-Control-Allow-Origin value changes per request. Without Vary: Origin, a CDN may cache a response with Access-Control-Allow-Origin: https://app-a.com and serve it to requests from https://app-b.com, causing those requests to fail with CORS errors. Conversely, an overly broad Vary: Origin bypasses the CDN cache entirely for every unique origin. The CORS checker flags missing or incorrect Vary headers as a configuration warning.
What is the difference between simple and preflighted CORS requests?
Simple requests (GET/POST/HEAD with simple content types and no custom headers) are sent directly; the browser checks the response's Access-Control-Allow-Origin after the fact. Non-simple requests trigger a preflight OPTIONS exchange first. The distinction matters for API design: accepting JSON bodies (Content-Type: application/json) or Authorization headers always triggers a preflight. You can reduce preflight overhead by increasing Access-Control-Max-Age (up to 7200 seconds in Firefox, 600 in Chromium) or restructuring APIs to use query parameters for tokens instead of custom headers.