What is a CORS misconfiguration?

Cross-Origin Resource Sharing (CORS) controls whether browsers expose JavaScript responses across different origins. A CORS misconfiguration can let an untrusted website read sensitive application responses through the browser of an authenticated user.

What is the same-origin policy?

An origin consists of scheme, host and port. The same-origin policy normally prevents a script on evil.example from reading responses from bank.example. Sending certain cross-origin requests may still be possible; the main protection concerns access to the response. CORS deliberately relaxes this browser boundary through HTTP headers.

How does CORS work?

The browser sends an Origin header. The server can name an allowed origin through Access-Control-Allow-Origin. For cookies or other browser-managed authentication, Access-Control-Allow-Credentials: true also matters. Non-simple methods and headers first trigger an OPTIONS preflight. The browser enforces the result; CORS is not a replacement for server-side authentication or authorization.

Which misconfigurations are dangerous?

Browsers do not permit wildcard origin * together with credential mode for cookie-authenticated responses. It can still be risky when unauthenticated endpoints expose sensitive information or are expanded later.

What impact is possible?

An attacker can lure a victim to their site and read profile data, API responses, CSRF tokens or internal information from there. Depending on permitted methods, data may also be changed. Impact is determined by the victim's privileges and affected endpoint content. A broad CORS rule over public data alone is usually a configuration concern rather than a critical vulnerability.

How is CORS configured securely?

• Allow only necessary, complete origins from a server-side allowlist.
• Avoid dynamic reflection and fuzzy suffix or regular-expression checks.
• Limit credentials, methods and headers to the actual use case.
• Do not trust subdomains merely because they share a parent domain.
• Configure CORS centrally, include error responses and set Vary: Origin correctly.
• Continue authenticating and authorizing every endpoint server-side.

Code example: reflect or exactly allow an origin

Vulnerable:

$origin = $request->header('Origin');
return $response
    ->header('Access-Control-Allow-Origin', $origin)
    ->header('Access-Control-Allow-Credentials', 'true');

Safe with complete origins:

$allowedOrigins = [
    'https://app.example.com',
    'https://admin.example.com',
];
$origin = $request->header('Origin');

if (in_array($origin, $allowedOrigins, true)) {
    $response->headers->set('Access-Control-Allow-Origin', $origin);
    $response->headers->set('Access-Control-Allow-Credentials', 'true');
    $response->headers->set('Vary', 'Origin');
}

Central framework configuration is preferable to repeated controller code. The example highlights exact comparison and the necessary caching signal.

How is CORS tested?

Testers vary origin values using external domains, similar hostnames, subdomains, null and unusual ports. They inspect simple requests, preflights, credentials and caches. Only a browser proof shows whether a response is actually readable. The final assessment considers what data or actions a realistic victim account exposes.