CORS misconfiguration

By default a browser lets a page send certain cross-origin requests but not read the responses. CORS is the mechanism a server uses to grant that read, by returning Access-Control-Allow-Origin with an origin it trusts. For requests carrying cookies or credentials the server must also return Access-Control-Allow-Credentials: true, and in that case the browser refuses a wildcard: the origin has to be named explicitly.

That constraint is what leads to the bug. Because a static list is inconvenient, applications commonly read the Origin request header and echo it back, which grants access to whatever origin asked. Combined with credentials, that is a blanket permission for every website on the internet to read authenticated responses from the API using the visiting user’s session.

Origin validation is written as string matching and the matching is wrong. A check for a suffix accepts an attacker domain ending in the same characters. A check for a prefix accepts a subdomain of an attacker’s registration. A regular expression with an unescaped separator matches more than intended. Reflecting the literal null origin, which sandboxed frames and some redirects produce, hands access to any page that can generate it.

The framing that gets this wrong in reports is calling CORS a security control for the API. It is not one. It is a browser instruction, and a non-browser client ignores every header here, so a permissive policy does not create an exposure for scripted clients and a restrictive policy does not protect the endpoint from them. It matters exactly when the credential is attached automatically by a browser, which is why an API authenticated by a bearer token in a header is affected differently from one authenticated by a cookie. Getting that distinction wrong is common in API reports. And a hostile subdomain reached through subdomain takeover makes an otherwise reasonable wildcard over your own domain into a working exploit.

We send requests with a controlled origin, a subdomain of the real one, a suffix collision and the null origin, and we record which combinations return an allow header together with credentials. The proof is a page on our origin reading an authenticated response, not the header on its own, because a permissive header on an endpoint that returns nothing sensitive is a hygiene note. The report names the endpoint, the accepted origins and the data recovered. This is part of how we review cross-origin exposure on an API.