CORS Misconfiguration Lab: Steal a Token From Another Site

This article presents a hands-on CORS misconfiguration lab that demonstrates how servers reflecting the Origin header while setting Access-Control-Allow-Credentials: true create a critical vulnerability. The flaw allows attackers to make authenticated requests to a victim's account and read sensitive responses like auth tokens. Understanding this misconfiguration is essential because it is among the most common CORS findings in real-world bug-bounty programs and directly enables account takeover.

• The dangerous CORS combination explainedWhen a server echoes back whatever Origin header it receives into the Access-Control-Allow-Origin response header and also sets Access-Control-Allow-Credentials: true, it tells the browser that every website is trusted to make authenticated requests and read responses. This pair is described as the worst CORS combination because it effectively disables the same-origin policy for all origins simultaneously.
• How the attack executes step by stepAn attacker creates a page that sends a fetch request to the victim's bank endpoint (/me) with credentials included. Because the server reflects the attacker's origin and permits credentials, the victim's session cookie automatically attaches to the request. The browser then allows the attacker's script to read the JSON response, from which the auth token can be extracted and submitted.
• Why browsers enforce the misconfigurationCORS validation happens on the client side based on what the server declares in response headers. When a server reflects the requester's origin into Allow-Origin paired with Allow-Credentials: true, the browser interprets this as explicit permission from the server that this origin is trustworthy, so it allows the response to be read by that origin's script.
• Real-world prevalence and impactOrigin-reflection with credentials is described as one of the most common CORS findings in bug-bounty programs because developers often use reflection as a quick fix to enable cross-origin functionality. The article maps this issue to OWASP's Security Misconfiguration (A05) category and notes it leads directly to account takeover when endpoints return tokens or personal data.
• Correct allowlist implementationThe defense requires maintaining a strict allowlist of explicitly trusted origins and only echoing the Allow-Origin header when the request's origin matches an entry on that list. Access-Control-Allow-Credentials: true must only ever accompany a single trusted origin from this list, never a reflected origin or wildcard.
• Detection technique for testersA practical way to identify this vulnerability is to send requests with Origin headers set to random or unregistered domains. If the server reflects these arbitrary origins into Access-Control-Allow-Origin alongside Allow-Credentials: true, the misconfiguration has been found.
• Additional defensive measuresBeyond strict allowlisting, the article recommends preferring same-site cookies and short-lived tokens so that if a response is leaked through this vulnerability, the leaked credentials have limited time-window utility. It also emphasizes that the Origin header should only be used to identify who is asking, not to determine authorization.

Bottom line: Never reflect the Origin header in Access-Control-Allow-Origin when allowing credentials; instead maintain a strict allowlist of trusted origins and only echo Allow-Origin for origins explicitly on that list. This single rule prevents account takeover attacks that exploit CORS misconfiguration to steal authenticated users' tokens and sensitive data.