CORS Misconfiguration Checker

Report

Raw probe responses

Common questions

What is a CORS misconfiguration and why does it matter?

CORS (Cross-Origin Resource Sharing) is a browser mechanism that lets a server explicitly allow another website to read its responses. A misconfigured server can end up trusting any origin at all, the literal origin "null", or an attacker-registrable domain that happens to satisfy a sloppy string check -- any of which lets an attacker's website read data (sometimes including a logged-in visitor's authenticated data) it should never see.

Why does this need a CLI instead of just checking a URL I type into the page?

Origin is a forbidden request header under the Fetch spec, so a browser tab is never allowed to set it to anything other than the page's own real origin -- that restriction is part of what CORS protects. Only a non-browser HTTP client, like the CLI here (or curl), can send the crafted Origin headers this check depends on. Run the CLI, then paste its JSON output here for a rendered report.

Is it safe to run this against a URL?

It sends six ordinary, unauthenticated GET requests -- nothing here bypasses authentication, reads protected data, or does anything a browser wouldn't also do by visiting the URL with different Origin headers. Only point it at a system you own or are authorised to test, the same rule that applies to any request tool aimed at someone else's server.

Does a clean report mean the API has no CORS issues?

No. This checks four specific, well-documented misconfiguration patterns using six requests -- it is not a full security assessment, does not test authenticated endpoints with real credentials, and cannot see a bypass this tool's four attack probes don't happen to trigger. Treat a clean report as evidence about these specific patterns, not a determination that the API is secure.

Why does one of the six requests send my own origin?

That request is not an attack and echoing it back is never reported as a finding -- allowing your own origin is the correct answer. It is there for the Vary: Origin notice, which is about the caching layer in front of the API rather than the allow-list behind it. On a server whose allow-list works, all four attack origins are correctly rejected, so nothing else in the run would ever show that the response still changes with the request. The sixth request does, and the request that sends no Origin header at all is what tells a dynamic header from a static one: a value that is identical whether or not you send an Origin is the same response for everybody and owes no Vary.

More background: what a reflected-origin CORS misconfiguration actually lets an attacker do.

Already testing with a full web security platform? See how this checker compares to Burp Suite — a six-request CI gate next to an interactive assessment tool, and when each one is the right answer. Testing with plain curl instead? See how this checker compares to sending a crafted Origin header yourself — one curl request finds the obvious reflected-origin bug, but the other three patterns only surface by comparing several requests side by side.