CORS: how it works, and how it is misconfigured

A practical walk-through of the headers is on MDN.

An origin is the combination of scheme, host and port: https://shop.example and https://api.example are different origins. Browsers let a page send requests to any origin, but read the response only from its own. That rule is what stops a random website from reading your email or bank balance through your signed-in browser.

CORS is a controlled exception. The server answers with headers naming which origins may read the response, and the browser enforces it. CORS never protects the server: it decides what pages in a browser may read, and tools outside a browser ignore it.

• Origin. The browser adds this header to cross-origin requests, naming the page's origin.
• Access-Control-Allow-Origin. The server names one origin that may read the response, or * for any origin.
• Access-Control-Allow-Credentials: true. Allows the response to be read when the request carried cookies; browsers refuse this together with *.
• Preflight request. For methods other than GET, HEAD and simple POST, or with custom headers, the browser first sends an OPTIONS request and proceeds only if the answer allows it.
• Access-Control-Allow-Methods and -Headers. The preflight answer listing what the real request may use.

If the response names a different origin, or none, the browser still receives it but refuses to hand it to the page. That refusal is what developers see as a CORS error.

A message such as “blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present” means the browser did its job: the server did not say the page's origin may read the response. The request may well have reached the server and run; only the reading was blocked.

The fix is on the server that owns the resource: return the right Access-Control-Allow-Origin for the origins that legitimately call it, and answer preflight requests. Browser extensions that switch CORS off, or a proxy that adds * to everything, make the error disappear by removing the protection.

• Reflecting any Origin with credentials. The server copies whatever arrives in Origin into the allow header and adds Allow-Credentials: true. Any website can now read a signed-in user's data.
• Loose matching. A check that the origin ends with example.com also accepts attacker-example.com; one that it starts with it accepts example.com.attacker.net.
• Allowing the null origin. Sandboxed frames and local files send Origin: null, and attackers can produce it on purpose.
• Trusting every subdomain. One forgotten subdomain with an XSS flaw then becomes a way to read the main API.
• Allowing plain HTTP origins. An attacker on the network can inject script into the HTTP page, which the HTTPS API then trusts.

A wildcard * on public data that needs no sign-in is fine. The danger is always in combining a permissive origin with responses that depend on who the user is.

CORS controls reading, not sending. A cross-site form can still submit to your site, and the browser will still attach cookies according to their SameSite setting; CORS only decides whether the attacker's page can see the answer. Protection against forged actions comes from CSRF tokens and SameSite cookies.

A strict CORS policy does make some requests harder to forge, because a preflight stops JSON requests with custom headers from other origins. That is a side effect, not a design you should rely on.

1. Keep an explicit allowlist. Compare the full origin, scheme and port included, against a fixed list.
2. Send credentials only where needed. Most cross-origin calls do not need cookies; leave Allow-Credentials off unless they do.
3. Never reflect Origin unchecked, and never allow null. Both are equivalent to allowing everyone.
4. Add Vary: Origin. When the allow header depends on the request, caches must not serve one origin's answer to another.
5. Return CORS headers only on endpoints called cross-origin. Not site-wide; the broader header set is on security headers.

Almost nothing. A CORS misconfiguration is in the response headers your server sends, and its effect happens inside the victim's browser when another site reads the response. The requests involved are ordinary requests with an Origin header.

Finding it is a matter of testing: send requests with unusual Origin values and read what comes back in Access-Control-Allow-Origin. The fix is a line of configuration in the application or the server in front of it.