CORS Configuration Audit
Enter a URL or API endpoint to test its Cross-Origin Resource Sharing policy for the misconfigurations that let a malicious website read your responses. The scanner sends a few harmless GET requests with crafted Origin headers — exactly what a browser sends on a cross-origin request — and reads back the Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers. It flags the dangerous shapes: a server that reflects any Origin, one that also allows credentials (so any site can read authenticated data), a server that trusts the special null origin, and an allowlist that can be bypassed by an attacker domain that merely contains your hostname.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Origin reflection — does the server echo back any Origin it receives in Access-Control-Allow-Origin?
- Credentialed reflection — is Access-Control-Allow-Credentials: true sent together with a reflected origin (the critical, account-takeover-class bug)?
- Null-origin trust — is the special "null" origin accepted (reachable from sandboxed iframes and some redirects)?
- Allowlist bypass — does the check match by substring/suffix so https://yourdomain.attacker.example slips through?
- Wildcard policy — is Access-Control-Allow-Origin set to "*" (acceptable only for genuinely public data)?
How to read the result
- OK = the origin checks held up: no arbitrary, null or bypass origin was reflected (or there are no CORS headers at all).
- Critical (fail) = any website can read AUTHENTICATED responses — the server reflects the request Origin and sends Access-Control-Allow-Credentials: true. Fix immediately.
- Warn = the policy is too loose: it reflects any origin without credentials, trusts the null origin, or has a bypassable allowlist. Tighten it to an exact-match allowlist.
- Info = Access-Control-Allow-Origin is the wildcard "*" — fine for public data, but make sure this endpoint never returns anything session-specific.
- Each finding shows the exact Origin that was sent and the header that came back, so you can reproduce it with a one-line curl.
Frequently asked questions
Why is reflecting the Origin with credentials so dangerous?
If a server copies the request's Origin into Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true, then a malicious page open in any of your users' browsers can make a cross-origin request to your endpoint with the user's cookies and read the response. That exposes session-scoped data, CSRF tokens and account information — effectively a cross-site account-takeover primitive.
Is the test safe and non-destructive?
Yes. Every probe is a single ordinary GET that only adds an Origin header — the same thing any browser does on a cross-origin fetch. Nothing is written, brute-forced, exploited or flooded; the tool just reads the CORS response headers and reasons about them.
What is the null origin and why does it matter?
Browsers send Origin: null from sandboxed iframes, data: documents and certain redirect chains. If a server allowlists "null", an attacker can force that origin from a sandboxed iframe and abuse the endpoint just like a reflected origin — so "null" should never be in your trusted set.
How do I fix a CORS misconfiguration?
Never reflect the Origin blindly. Compare it against an explicit allowlist using exact string equality (full scheme + host), echo it back only on a match, and only enable Access-Control-Allow-Credentials for those exact origins. Avoid checks like origin.endsWith("example.com") or origin.includes(host) — they are trivially bypassed by example.com.attacker.example.