CORS Misconfiguration: The Silent Risk of Opening Your Origin to Everyone

CORS (Cross-Origin Resource Sharing) determines when a browser will allow a web page to read data from a different origin. A common misconception is that CORS is an attack; in fact it is a way to deliberately relax the browser’s Same-Origin Policy. When misconfigured, it exposes the very data it is meant to protect.

First, the Same-Origin Policy

Browsers block a page from reading a response from a different origin by default (Same-Origin Policy). “Origin” = scheme + host + port. This is the fundamental boundary that stops a malicious site from reading your API’s data using the victim’s session.

CORS is the standard way to intentionally relax that boundary: your API states, “I allow requests from this origin to read my response,” via the Access-Control-Allow-Origin header.

The most dangerous mistake: origin reflection + credentials

The critical misconfiguration is reflecting the origin without validation on an authenticated (cookie/token) API. Some servers echo the incoming Origin header verbatim:

Access-Control-Allow-Origin: https://attacker.example
Access-Control-Allow-Credentials: true

Here the server declares whatever origin arrives as allowed, and permits credentials. The result: a malicious site can read authenticated data from your API using the victim’s session. The specification does not allow Access-Control-Allow-Origin: * together with Allow-Credentials: true; the attack works precisely where the origin is reflected.

The wildcard itself (Access-Control-Allow-Origin: *) is fine for a public, unauthenticated endpoint; the real danger is origin reflection on authenticated data.

Safe configuration principles

1. Validate origins against an allowlist. Compare the incoming Origin against a fixed list; if it matches, reflect that specific origin, otherwise send no header at all.
2. Only set Allow-Credentials: true when genuinely required, and never combine it with a wildcard or reflected origin.
3. Open only the methods and headers you need.
4. Do not trust the null origin; some contexts send Origin: null, and allowlisting it can be bypassed.

How to test

curl -sI -H "Origin: https://random-attacker.example" https://api.yoursite.com/data \
  | grep -i access-control-allow

If the response reflects your fake origin and especially access-control-allow-credentials: true, the endpoint is unsafe.

What CORS does NOT protect

CORS is not an authorisation layer. It restricts reading the response but does not stop the request from reaching the server. Server-side authorisation is still mandatory, and CORS alone does not solve CSRF.

Summary

Think of CORS as a gate deciding which sites may read your data. Opening it to everyone (*) is fine for public data, but reflecting the origin plus credentials is a fatal combination on authenticated APIs. Validate origins against an allowlist, grant credentials sparingly, and use the wildcard only on unauthenticated endpoints.

Sources: MDN: CORS, PortSwigger: CORS.

Not sure if your API’s CORS headers are safe? CyberTestify’s external surface scan detects common CORS misconfigurations from real captured responses.