What this tool checks
Cross-Origin Resource Sharing (CORS) is the mechanism that decides whether JavaScript running on other-site.com is allowed to read a response from your-site.com. By default, browsers block this — CORS headers are how a server explicitly opts back in, and how much it opts into matters. This tool sends a single request carrying a synthetic Origin header and inspects exactly what the server allows back: whether it names a specific origin, uses a wildcard, or — the risky case — blindly echoes back whatever origin it receives.
Why origin reflection is the real danger
A wildcard (Access-Control-Allow-Origin: *) looks permissive, but browsers refuse to attach cookies or HTTP auth to a wildcard-origin response, so it can't expose anything a visitor is logged into. Origin reflection is different: because the server copies the exact Origin header back instead of using a literal *, it isn't a wildcard from the browser's perspective — which means it can be paired with Access-Control-Allow-Credentials: true. That combination lets any website make a credentialed request to your API on a logged-in visitor's behalf and read the response, which is functionally equivalent to a cross-site request forgery vulnerability with response-reading attached.
A common way this happens by accident
Teams often implement CORS by grabbing the incoming Origin header and echoing it back — sometimes to support several front-end domains (staging, production, a marketing site) without hand-maintaining an allowlist. It works for all of them, and for every other origin too, since nothing was ever actually checked. The fix is almost always the same: replace the echo with a real allowlist comparison.