CORS Checker
Test cross-origin headers and preflight behaviour
Sends a genuine cross-origin request from an origin that cannot be on anyone's allowlist, then reports exactly what came back. That is what makes the dangerous case visible: a server that returns Access-Control-Allow-Origin for an origin it has never heard of is not allowlisting, it is reflecting whatever it was sent — and combined with Allow-Credentials, that lets any site on the internet make authenticated requests to yours and read the answers.
Frequently asked questions
What origin do you send?
https://cors-probe.example. The .example top-level domain is reserved and can never be registered, so if a server allows it, that server allows anything — the result cannot be a false positive caused by our origin happening to be trusted.
Why is origin reflection risky?
It is a wildcard written the long way. On its own it is only as dangerous as a wildcard; combined with Access-Control-Allow-Credentials: true it is much worse, because browsers will then send the visitor's cookies and let the calling site read the response. Allowlist specific origins instead.
Why does Vary: Origin matter?
If the Allow-Origin header changes depending on who asks, any shared cache in front of the server — a CDN, a reverse proxy — can store the header generated for one origin and hand it to another. Vary: Origin tells those caches to keep the responses apart.
My preflight returns a redirect. Is that a problem?
Yes. Browsers refuse to follow redirects on a preflight and treat one as an outright failure. It usually happens when OPTIONS is redirected to add or remove a trailing slash, or to move to the canonical hostname.
No CORS headers came back. Is my site broken?
Almost certainly not. Most URLs should not be readable cross-origin, and no Access-Control-Allow-Origin is the correct, safe default. It only matters if you intend other sites to fetch this URL from a browser.