CORS Misconfigurations: What They Are and How Attackers Exploit Them

Browsers enforce a rule called the same-origin policy: by default, a script running on one website can't read data returned by a different website. CORS (Cross-Origin Resource Sharing) is the mechanism servers use to deliberately relax that rule — and misconfiguring it is one of the more common ways private data ends up exposed.

How CORS Is Supposed to Work

A server sends back an Access-Control-Allow-Origin header naming exactly which other origins are allowed to read its responses. If a browser sees a response without that permission for the requesting page's origin, it blocks the page's script from reading the data — even though the request itself already happened.

The Dangerous Pattern: Reflecting Any Origin

Some servers, instead of maintaining a fixed allowlist, simply copy whatever Origin header the browser sent back into Access-Control-Allow-Origin — effectively saying 'yes' to any website that asks. On its own this is risky; combined with Access-Control-Allow-Credentials: true, it becomes a serious vulnerability.

Why Credentials Make It Worse

When credentials are allowed alongside a reflected origin, a malicious website can make a request to the victim's API using the victim's own logged-in browser session, and then actually read the private response — bank balances, personal data, account details — all without ever touching the user's password.

How to Test For It

Send a request to an API with a deliberately unusual Origin header (like an attacker-controlled domain) and check whether the response reflects that same origin back with credentials allowed. If it does, that endpoint likely has this exact vulnerability.

Scan Your Site

Nexora Shield's CORS Checker automates this test against any URL, flagging origin reflection and credential exposure so you don't have to test it manually.