Home / Knowledge hub / CORS misconfiguration
Knowledge hub
CORS misconfiguration
A CORS setup that lets sites you never meant to trust read your API responses.
What it means
CORS is how a server tells browsers which other sites may read its responses. A misconfiguration is when that permission is wider than intended: it names sites you do not control, trusts any origin, or allows credentials alongside a weak rule.
The classic mistake is copying the request's Origin header straight into Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials: true. Every site then gets to read responses as the signed-in visitor.
Why it matters
The browser's same-origin policy normally stops one site reading another's data. A loose CORS rule removes that protection for your API. A visitor opens a hostile page, and that page quietly reads their account data, tokens or invoices from your service.
No password is stolen and nothing looks odd in your logs, because the request comes from the real user's browser. It is a quick route to data exposure with only a link needed.
How it shows up
You meet it in API gateways, framework middleware and cloud storage settings. Typical errors: reflecting any origin, trusting the string null, matching origins with a loose pattern so example.com.evil.net passes, or trusting every subdomain including forgotten ones.
Browsers refuse a wildcard * together with credentials, so developers reflect the origin instead, and that is where it goes wrong. Fix it with an exact allowlist of origins, and send no CORS headers on endpoints that need none. Test with a hostile Origin header.
Questions people ask
CORS misconfiguration, answered
Is Access-Control-Allow-Origin: * always a problem?
No. For public data that needs no sign-in, a wildcard is fine. It becomes a problem when responses are private or depend on cookies.
Browsers will not combine a wildcard with credentials.
Does CORS protect my API from attackers?
No. CORS is enforced by browsers. A script, curl or another server ignores it completely.
It protects visitors' data from being read by other sites, not your API from being called.
Why is trusting the null origin dangerous?
Some sandboxed frames and local files send Origin: null. An attacker can create one, so trusting it lets them read credentialed responses.
Never put null in an allowlist.
How do we fix a reflected origin?
Replace it with a fixed list and compare the whole origin exactly, including scheme and port. Add Vary: Origin so caches do not mix responses.
Do not use pattern matching on parts of the string.
How would a pentest find it?
By sending requests with different Origin values and checking which are echoed back with credentials allowed, then building a page that reads the data.
The report shows the request, the response and the data read.
Sources
Where this comes from
Related
Terms that sit next to this one
CORS
The browser rule for which sites may read responses from your API.
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
CSRF
An attacker's page makes a logged-in user's browser act on your site.
API
The part of your application other software talks to, not a person.
Allowlist
A list of what you permit, with everything else refused by default.
Which sites can read your API?
Reflected origins, trusted nulls and credentialed responses that another site can read are things we test and prove, with the request and the data returned. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.