Headers & Policies

July 14, 2026 · 2 min read

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.

Common CORS mistakes

Reflecting the request's Origin header back verbatim as `Access-Control-Allow-Origin` to 'make CORS errors go away' during development, then shipping that code to production unchanged — this effectively allows any website on the internet to make authenticated requests to the API on a logged-in user's behalf.

Setting `Access-Control-Allow-Credentials: true` alongside a wildcard or overly broad origin list. Browsers actually block this specific combination outright for wildcards, but a broad allowlist (like allowing any subdomain via a loose regex) can achieve the same dangerous effect while technically passing browser checks.

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.

Frequently Asked Questions

Is using a wildcard (*) for Access-Control-Allow-Origin always dangerous?

It's safe for fully public, non-authenticated APIs, but dangerous the moment credentials or cookies are involved — browsers actually block wildcard origins from being used together with credentials for this exact reason.

How do I fix a reflected-origin CORS misconfiguration?

Replace the dynamic origin-reflection logic with a fixed allowlist of specific, trusted origins, and only enable Access-Control-Allow-Credentials for those explicitly trusted domains.

CORS Checker

Tests any URL for origin reflection and credential exposure automatically.

Try the CORS Checker

Related Articles