How to Find CORS Misconfiguration Bugs (With Real Impact)
CORS controls which websites may read responses from your API in a browser.
A misconfiguration is only exciting when an evil page can read authenticated sensitive data from a victim’s session.
Quick takeaway: Check
Access-Control-Allow-Origin+Allow-Credentials→ try a malicious origin → prove you can read a private JSON response from the victim’s browser.
What “bad CORS” looks like
Common weak patterns:
- Reflecting any
Originheader - Allowing
nullorigin carelessly - Combining wide ACAO with
Access-Control-Allow-Credentials: true
Wide ACAO without credentials is often less severe for cookie-based apps — say so honestly.
Hunting steps
- Find an authenticated API that returns PII or tokens
- Send it with an attacker
Origin - See if ACAO mirrors that origin and credentials are allowed
- Build a minimal HTML PoC that reads the response using the victim’s cookies
- Show the sensitive fields (redacted) in your report
Impact sentence examples
Strong: “Any malicious website can read the /api/me response for a logged-in user, including email and account id.”
Weak: “CORS header is present.”
Fixes
- Explicit origin allowlists
- Avoid reflecting arbitrary origins
- Be careful with credentialed CORS
- Prefer token designs that do not rely on cookie auth for cross-site APIs when possible
Original Bugflare article. Concepts aligned with PortSwigger CORS academy topics.