The Origin It Trusted: A Credentialed CORS Reflection
The challenge
Halcyon's account API answers browser requests from its own web app, and to make that work across a couple of domains the team let the server decide per request. It reads the Origin header the browser sends and, if it looks like one of theirs, echoes it straight back as the allowed origin and says credentials are welcome. An attacker's page can send any Origin it likes. Change the Origin to the attacker's site and read what the API hands back to it.
What you'll learn
- Explain what Access-Control-Allow-Origin and -Allow-Credentials do together
- Recognise reflecting an arbitrary Origin plus credentials as allowing every site
- Reproduce the read by sending an attacker Origin
- Explain why the browser then lets the attacker page read the response
- State the allowlist-based fix and the wildcard-plus-credentials ban
Skills tested
Prerequisites
- The same-origin policy at a high level
- What the Origin header is
How it works
CORS lets a server opt specific other origins into reading its responses. The server names an allowed origin in Access-Control-Allow-Origin, and may add Access-Control-Allow-Credentials: true to permit cookies. The browser enforces whatever the server says.
Reflecting the request's Origin verbatim into that header, together with allowing credentials, tells the browser that whichever site made the request may read the response with the victim's cookies. That is every origin, which is exactly what the explicit rule against Allow-Origin: * with credentials was meant to prevent; reflection sidesteps the rule while having the same effect.
A logged-in victim who visits the attacker's page triggers a credentialed request, and the attacker's script is allowed to read the private body.
Common mistakes
- Leaving the real app origin. It works too, but the point is that a site you control is also accepted.
- Dropping the cookie. Without the victim session the API returns 401; the attack relies on the browser attaching it automatically.
- Answering with a header value. The prize is the account data in the body, specifically the email.
- Thinking the same-origin policy protects this. The server explicitly waived it by reflecting the origin and allowing credentials.
How to defend against it
Validate the origin; never reflect it blindly with credentials.
- Compare
Originagainst a strict allowlist and echo back only a matched, known value. - Never pair
Access-Control-Allow-Credentials: truewith a reflected or wildcard origin. - Keep sensitive reads behind authorization that does not rely on the browser's same-origin policy, and scope cookies tightly.