An Access-Control-Allow-Origin that echoes your probe is a misconfiguration worth noting - one that also returns Access-Control-Allow-Credentials: true is the one that hands a cross-origin attacker your session.
Most CORS findings are raised the instant a scanner sees the server echo back whatever Origin it was sent. That is real, but it is reachability: the trust list is loose. The finding that actually hands a cross-origin attacker your session is the specific pair - a reflected origin returned together with Access-Control-Allow-Credentials: true. Reflection is a note; the pair is a breach.
The browser will only expose a cross-origin response that carries credentials if two headers agree: the response must name the attacker's exact origin in Access-Control-Allow-Origin and it must also say Access-Control-Allow-Credentials: true. A wildcard origin with credentials is spec-illegal and the browser refuses it. So the dangerous configuration is narrow and specific, which is exactly why it should be confirmed, not assumed.
The confirming artifact is a single response: send a request with an attacker-controlled origin and observe the server return both headers for that exact origin. The probe origin is a benign marker domain that holds no real user's cookie, so demonstrating the misconfiguration never exfiltrates a real session or any real data.
# request carries a benign, attacker-shaped origin GET /api/account HTTP/1.1 Origin: https://ap-probe.example Cookie: <test-account session, never a real user> # response reflects that exact origin AND allows credentials == confirmed HTTP/1.1 200 OK Access-Control-Allow-Origin: https://ap-probe.example Access-Control-Allow-Credentials: true
The same header family spans three very different findings, and collapsing them into one is how CORS gets both over-reported and under-rated.
| Configuration | What it allows | Rating |
|---|---|---|
| Reflect any origin + ACAC: true | Arbitrary cross-origin authenticated reads | Critical - confirmed |
| Reflect any origin, no ACAC | Cross-origin reads of non-credentialed data | Medium - depends on the data |
| ACAO: * , no ACAC | Public data only; browser blocks credentials | Low / informational |
The controlled origin never carries a real user's cookie, so confirmation cannot leak a real session, and any sensitive values that do appear in a response are masked in the evidence we store. The point is to prove the boundary is open, not to walk through it with someone else's identity.
Pin the allowed origins to an explicit allowlist and drop credentials for anything public. The reflected origin stops being a door the moment it stops being dynamic.