CORS Analyzer

CORS does not protect a server. It relaxes a browser rule — the same-origin policy — that would otherwise stop one site reading another's responses. Every CORS header is therefore a grant, and the question worth asking of one is what it gives away rather than what it defends.

The combination that matters

A wildcard origin is fine for genuinely public data and a disclosure for anything that varies by user or by network position — an internal API readable by any page an employee visits is the usual case. Credentials change the stakes entirely: with Access-Control-Allow-Credentials: true, cookies ride along and the allowed origin reads the authenticated response.

Why a reflected origin looks identical to a safe one

A server that echoes back whatever Origin it received produces a response indistinguishable from one naming a single trusted site. From headers alone that distinction cannot be made, so a specific origin is reported as scoped with that caveat attached. Send the request again with a different Origin header — if the response changes to match, the allowlist is everything.

Vary: Origin is not cosmetic

Without it a shared cache stores one origin's response and serves it to another. Where the origin is reflected, that turns a CDN into a way of handing one site the headers meant for a different one.

Access-Control-Allow-Origin: null is the most dangerous single value here. Any sandboxed iframe sends Origin: null, and any site can create one — so this allowlists an origin an attacker produces on demand. It is almost always the accidental output of reflecting an Origin the server did not expect.