Was ist eine CORS-Fehlkonfiguration?

Cross-Origin Resource Sharing (CORS) steuert, ob Browser JavaScript-Antworten zwischen unterschiedlichen Ursprüngen freigeben. Eine CORS-Fehlkonfiguration erlaubt einer nicht vertrauenswürdigen Website, sensible Antworten einer Anwendung im Browser eines angemeldeten Nutzers auszulesen.

Was ist die Same-Origin Policy?

Ein Origin besteht aus Schema, Host und Port. Die Same-Origin Policy verhindert grundsätzlich, dass ein Skript von evil.example Antworten von bank.example lesen kann. Das Absenden bestimmter Cross-Origin-Requests ist teilweise möglich; geschützt wird vor allem der Zugriff auf die Antwort. CORS lockert diese Browsergrenze gezielt durch HTTP-Header.

Wie funktioniert CORS?

Der Browser sendet den Origin-Header. Der Server kann mit Access-Control-Allow-Origin einen erlaubten Ursprung nennen. Bei Cookies oder anderer Browser-Authentifizierung ist zusätzlich Access-Control-Allow-Credentials: true relevant. Nicht einfache Methoden und Header lösen zunächst einen OPTIONS-Preflight aus. Wichtig: Der Browser setzt die Entscheidung um; CORS ersetzt keine serverseitige Authentifizierung oder Berechtigungsprüfung.

Welche Fehlkonfigurationen sind gefährlich?

Der Wildcard-Origin * kann von Browsern nicht zusammen mit Credential-Mode für cookiebasierte Antworten verwendet werden. Er ist dennoch problematisch, wenn nicht authentifizierte Endpunkte vertrauliche Informationen liefern oder künftig erweitert werden.

Welche Auswirkungen sind möglich?

Ein Angreifer kann Opfer auf seine Website locken und von dort Profildaten, API-Antworten, CSRF-Tokens oder interne Informationen lesen. Abhängig von erlaubten Methoden lassen sich Daten zusätzlich verändern. Die Auswirkung wird durch die Rechte des Opfers und den Inhalt der betroffenen Endpunkte bestimmt. Eine großzügige CORS-Regel auf ausschließlich öffentlichen Daten ist meist eher eine Konfigurationsfrage als eine kritische Schwachstelle.

Wie konfiguriert man CORS sicher?

• Nur tatsächlich benötigte, vollständige Origins aus einer serverseitigen Allowlist zulassen.
• Keine dynamische Spiegelung und keine unscharfen Suffix- oder Regex-Prüfungen verwenden.
• Credentials, Methoden und Header auf den konkreten Anwendungsfall begrenzen.
• Subdomains nicht allein wegen gemeinsamer Hauptdomain als vertrauenswürdig behandeln.
• CORS zentral konfigurieren, Fehlerantworten einbeziehen und Vary: Origin korrekt setzen.
• Jeden Endpunkt weiterhin serverseitig authentifizieren und autorisieren.

Codebeispiel: Origin spiegeln oder exakt erlauben

Verwundbar:

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

Sicher mit vollständigen 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');
}

Eine zentrale Framework-Konfiguration ist besser als wiederholter Controller-Code. Das Beispiel zeigt die entscheidende exakte Prüfung und das notwendige Cache-Signal.

Wie wird CORS getestet?

Tester variieren Origin-Werte einschließlich fremder Domains, ähnlich benannter Hosts, Subdomains, null und ungewöhnlicher Ports. Sie prüfen einfache Requests, Preflights, Credentials und Caches. Erst ein Browsernachweis zeigt, ob eine Antwort wirklich lesbar ist. Anschließend wird bewertet, welche Daten oder Aktionen mit einem realistischen Opferkonto erreichbar wären.