How does the CORS checker test a URL?

It sends seven GET requests with different Origin headers, an arbitrary origin, the null origin, a prefix and suffix variant of your own host, an unknown subdomain, and the plain HTTP origin, plus one OPTIONS preflight. It then compares the Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers in each response.

Is a wildcard Access-Control-Allow-Origin dangerous?

A wildcard on public, unauthenticated content is fine. Browsers block credentials with a wildcard. The dangerous case is a reflected origin combined with Access-Control-Allow-Credentials: true, because any site can then read authenticated responses.

Does the checker exploit anything?

No. It reads response headers only and does not use any credentials. Strix confirms exploitability with a real cross-origin proof of concept during a pentest.

Scanners

CORS Checker

Free CORS misconfiguration checker. Send test origins to any URL and see if it reflects arbitrary origins, trusts null, allows credentials with a wildcard, or accepts subdomain and prefix bypasses.

How the checker works

The checker first follows redirects with a plain GET to find the final URL. It then sends seven GET requests and one OPTIONS preflight to that URL, each with a different Origin header, and compares Access-Control-Allow-Origin and Access-Control-Allow-Credentials across the responses. Only response headers are read. Results are cached for five minutes.

Probe	Origin sent	Finds
Arbitrary origin	https://cors-probe.strix.ai	Origin reflection
null origin	null	Trust of sandboxed iframes and redirects
Host as prefix	https://<host>.cors-probe.strix.ai	startsWith or unanchored regex checks
Host as suffix	https://strixprobe<apex>	endsWith checks without a leading dot
Unknown subdomain	https://strix-cors-probe.<apex>	Wildcard subdomain trust
HTTP origin	http://<host>	Trust of the insecure scheme
Preflight	OPTIONS with PUT and custom headers	Approved methods and headers for untrusted origins

Grades: A+ at 95 or more, A at 85, B at 70, C at 55, D at 40, E at 20, F below 20. Any untrusted origin that can read a response with credentials caps the grade at F. A wildcard * without credentials is informational, browsers never send cookies with it.

Why reflected origins matter

Browsers enforce the same-origin policy. CORS is the server telling the browser which other origins may read a response. When a server copies the request Origin into Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true, a page on any domain can make an authenticated request with the visitor’s cookies and read the result. On an endpoint like /api/me or /api/keys, that is account takeover in one click.

Fix checklist

Keep an explicit allow-list of full origins, scheme included. Compare with equality, not with a regex or a substring check.
Never add null to the allow-list.
Send Vary: Origin whenever the Allow-Origin value depends on the request.
Only send Access-Control-Allow-Credentials: true on endpoints that need cookies from another origin.
Prefer a single API origin and same-site cookies so most endpoints need no CORS at all.

What this tool does not do

It does not log in, so endpoints that only set CORS headers for authenticated sessions can look safe here.
It does not read response bodies or test other methods than GET and a PUT preflight.
It does not scan private or internal addresses.

Check the rest of the response with the security headers checker, or list every API host first with the subdomain finder.

Frequently asked questions

More free tools

Start testing in minutes

Connect your GitHub repos and domains, and get fully set up in a few clicks.

Start for free All free tools →