Paste your CORS response headers to read a graded security report. It flags the headline bug, an allow origin that reflects the caller while credentials are allowed, along with a forgeable null origin, wildcard misuse, multiple allowed origins, and a missing Vary on Origin.
Cross Origin Resource Sharing is the controlled way a server lets a page on one origin read responses from another origin. By default the browser same origin policy stops that, so a script on one site cannot read a response that came back from a different site. CORS is the opt in that relaxes the rule, and it is driven almost entirely by a handful of response headers. This tool parses those headers exactly as you paste them and audits the parts that decide whether the relaxation is safe, drawing on the Fetch standard CORS protocol and the guidance in the OWASP CORS notes.
Two URLs share an origin when their scheme, host, and port all match. The same origin policy lets a page send a request to another origin, but it stops the page from reading the response unless that other origin opts in. CORS is that opt in. The server answers with Access-Control-Allow-Origin to name who may read the response, and for anything beyond a simple request the browser first sends a pre flight OPTIONS request to ask permission. The headers you paste here are the server's side of that conversation.
The headline misconfiguration is a server that takes whatever Origin arrived on the request and echoes it straight back in Access-Control-Allow-Origin, while also sending Access-Control-Allow-Credentials: true. To a browser this reads as "any origin you came from is allowed to make a logged in request and read the answer". An attacker page at evil.example then makes a credentialed request to the victim API, the victim's cookies ride along, the server reflects evil.example as allowed, and the attacker script reads the authenticated response. The fix is never to reflect: keep a fixed allowlist of trusted origins and compare against it, returning a single fixed origin only when it matches.
A natural question is whether Access-Control-Allow-Origin: * plus credentials is the risk. It is not, because the browser refuses that exact combination: a credentialed request against a wildcard origin simply fails. That is precisely why a server that wants credentialed cross origin access cannot use the wildcard and instead has to echo a specific origin, which is how the reflection bug creeps in. A bare wildcard with no credentials is fine for a genuinely public read only API, but it is the wrong choice for anything that depends on the caller being logged in.
Allowlisting the literal value null looks harmless but is forgeable: a sandboxed iframe, a data: URL, or certain redirects send Origin: null, so an attacker can put their page in that state and slip through. Equally, the spec permits exactly one origin or the wildcard in Access-Control-Allow-Origin. A header carrying several space or comma separated origins is not valid CORS, and usually signals a broken attempt at reflection that the browser will reject anyway. The checker flags both.
A common misunderstanding is that CORS protects you from cross site requests. It does not. CORS governs whether a script may read a cross origin response; it does almost nothing to stop the request being sent in the first place. A state changing request can still leave the browser and hit your server before any CORS check applies. That is why CORS is not a defense against cross site request forgery, which is about unwanted writes and needs its own protections like anti forgery tokens and same site cookies. Loosening CORS to fix a CSRF problem only widens your read surface.
Each graded check contributes a weighted share of a score out of one hundred. A pass earns its full weight, a weak setting earns part of it, and a dangerous one earns none. The grade is a fast signal about the headers as you pasted them, not a verdict on the whole system. This tool reasons about the headers as text and cannot see how the endpoint is actually deployed, whether the API is authenticated, or what the server does on a non matching origin. Judging whether a configuration is truly safe means understanding how the server decides each origin, which is the kind of context an AI security testing approach reasons about rather than pattern matching one header. For the wider set of trust boundaries attackers probe, see the access control writing.