Quick answer: A CORS misconfiguration (Cross Origin Resource Sharing) is when a web application defines too loosely what permissions it grants to requests from other origins, letting an attacker site access sensitive data with the victim's session. The most common mistake is the server reflecting the requesting origin as is while also allowing access with credentials. In that case the attacker site can send a credentialed request to the API through the logged in user's browser and read the response. The root fix is to fix the allowed origins with a strict server side allow list, open credentialed access only to origins that are genuinely needed and trusted, and never use wildcard permissions together with credentials.

Browsers prevent a site from reading another origin's data without permission through the Same Origin Policy. CORS is the official way to relax this rule deliberately and in a controlled manner. But when misconfigured, the mechanism that provides protection turns into a flaw itself. This article explains how CORS works, typical configuration mistakes and the correct defense.

How CORS works

When a browser sends a request to a different origin, it looks at the permission headers in the server response. The server states with the Access Control Allow Origin header which origin can read the response, and with the Access Control Allow Credentials header whether access with credentials is allowed. The browser trusts these headers and opens the response to JavaScript or blocks it.

The problem is the server granting these permissions too generously. The most critical combination is the server reflecting the incoming origin without question together with allowing credentialed access.

Typical CORS configuration mistakes

Mistake What it does Why it is dangerous
Reflecting the origin Sets the incoming origin as Allow Origin as is Every site is treated as trusted
Wildcard plus credentials Allow Origin wildcard, Allow Credentials on Opens credentialed data to everyone
Trusting the null origin Allows the null origin Bypassed with a sandbox iframe
Weak domain matching Compares the domain loosely Bypass with a similar domain

Reflecting the origin and allowing credentialed access is in practice equivalent to fully removing the Same Origin protection.

Real impact

A CORS misconfiguration is not an open door on its own, it works through the victim's session. While the user is on the attacker's site, that site sends a credentialed request to the target API through the victim's browser and reads the response. The impact can be:

  • Reading sensitive data. Information such as profile, email and tokens leaks to the attacker site.
  • Identity and token theft. A session or API key in the response can be captured, which can lead to account takeover.
  • Chained attack. A CSRF token read via CORS can be used to bypass CSRF protection.
  • API key disclosure. Secret keys returned in the response are exposed to the attacker.

Difference between CORS, CSRF and XSS

These three web flaws are often confused but are different. CSRF makes the victim perform an unwanted action but cannot read the response. A CORS misconfiguration lets the attacker read the response. XSS runs code on the victim's site. A CORS flaw should not be underestimated because it can leak sensitive data even without XSS.

The correct defense

1. Strict allow list

Allowed origins must be kept in a fixed server side list. If the incoming origin exactly matches this list access is granted, otherwise it is rejected. The incoming origin must never be reflected without question.

2. Narrowing credentialed access

Access Control Allow Credentials must be opened only for origins that are genuinely needed and trusted. Wildcard Allow Origin must never be used together with credentials, browsers forbid it but it must also be consciously prevented server side.

3. Full domain validation

Origin comparison must be an exact match, not a substring. A domain that looks similar but belongs to the attacker must not match.

4. Closing null and unnecessary permissions

The null origin must not be trusted, and unneeded methods and headers must not be opened. The principle of least privilege applies to CORS too.

CORS scanning with KAOS

DSET's local AI security engine KAOS tests the CORS configuration with an evidence first approach. It tries the server's permission headers with different origin, null and subdomain vectors, detects the combination of origin reflection and credentialed access, and verifies in a controlled way whether a configuration actually opens sensitive data to a cross origin. It reports only genuinely exploitable configurations without false positive noise. So you clearly see whether an API you thought was safe lets another site read data with a user's session.

Frequently asked questions

I use a wildcard Allow Origin but do not send credentials, am I safe? If credentialed access is off the risk is much lower, because the attacker cannot read data with the victim's session. Still, make sure your public responses contain no sensitive information. The truly dangerous combination is wildcard or reflection together with credentialed access.

Does the browser not already enforce CORS, why bother on the server? The server makes the CORS decision, the browser only enforces it. If the server grants loose permission the browser follows that permission. So security is in the server side configuration.

Is a CORS flaw as dangerous as XSS? It depends on context. A CORS misconfiguration can leak sensitive data cross origin even without XSS. If credentialed access is on the impact is very serious. Both should be fixed as a priority.

Sources

To test the CORS configuration of your web application and API with a working proof, contact DSET. We provide penetration testing and secure code review from our Ankara Hacettepe Teknokent laboratory.