Web Security

CORS Policy Analyzer

Reads the Access-Control response headers together and flags the origin and credentials combinations that leak data.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste the Access-Control response headers, one per line.
  2. Select Analyze CORS.
  3. Start with the amber rows - those are the origin and credentials combinations worth reviewing.
  4. If the origin is reflected from the request at runtime, confirm your code checks it against an allow-list first.

What cors policy analyzer does

CORS goes wrong in combination, not in isolation. A wildcard origin is fine for public data and invalid the moment credentials are allowed. A specific origin looks careful until you learn it was reflected straight from the request, which makes it a wildcard in disguise. The single headers each read as reasonable; the danger is in how they add up.

Paste the Access-Control response headers and this reads them as a set: it calls out a wildcard-plus-credentials policy that browsers reject, a null origin, a per-origin policy missing its Vary: Origin, and the credentialed settings that make a loose origin actually exploitable. It runs entirely in your browser - nothing you paste is sent anywhere, and this tool does not contact, scan or attack any website. Only review systems you own or are authorised to assess.

Frequently asked questions

The CORS specification forbids it, so browsers ignore the combination and block the request. To allow credentialed cross-origin access you must return one specific origin, not a wildcard - which is why servers often reflect the request Origin, and why doing that without an allow-list is dangerous.

No. It reads the response headers you paste and reasons about them. It does not send a request to your API or any other server. To see the headers in the first place, use your browser developer tools or a command-line request you run yourself.

When you return a per-origin Allow-Origin with credentials, a shared cache can store the response for one origin and serve it to another unless you add Vary: Origin. It is a caching correctness issue that becomes a security one.