CORS-Fehlkonfiguration: Das stille Risiko, den Origin für alle zu öffnen

CORS (Cross-Origin Resource Sharing) legt fest, wann ein Browser einer Webseite erlaubt, Daten aus einem anderen Origin zu lesen. Ein verbreitetes Missverständnis: CORS sei ein Angriff. Tatsächlich ist es eine Methode, die Same-Origin-Policy des Browsers bewusst zu lockern. Falsch konfiguriert gibt es genau die Daten preis, die es schützen soll.

Zuerst: die Same-Origin-Policy

Browser verhindern standardmäßig, dass eine Seite die Antwort eines anderen Origins per JavaScript liest (Same-Origin-Policy). “Origin” = Schema + Host + Port. Das ist die grundlegende Grenze, die verhindert, dass eine bösartige Seite die Daten Ihrer API mit der Sitzung des Opfers liest.

CORS ist der Standardweg, diese Grenze absichtlich zu lockern: Ihre API erklärt über den Header Access-Control-Allow-Origin, “Anfragen von diesem Origin dürfen meine Antwort lesen.”

Der gefährlichste Fehler: Origin-Reflection plus Credentials

Die kritische Fehlkonfiguration ist, den Origin bei einer authentifizierten (Cookie/Token) API ohne Prüfung zu spiegeln. Manche Server geben den eingehenden Origin-Header unverändert zurück:

Access-Control-Allow-Origin: https://angreifer.example
Access-Control-Allow-Credentials: true

Hier erklärt der Server jeden ankommenden Origin für erlaubt und lässt Credentials zu. Die Folge: Eine bösartige Seite kann mit der Sitzung des Opfers authentifizierte Daten aus Ihrer API lesen. Die Spezifikation erlaubt Access-Control-Allow-Origin: * nicht zusammen mit Allow-Credentials: true; der Angriff funktioniert genau dort, wo der Origin gespiegelt wird.

Die Wildcard selbst (Access-Control-Allow-Origin: *) ist für einen öffentlichen, nicht authentifizierten Endpunkt in Ordnung; die eigentliche Gefahr ist die Origin-Reflection bei authentifizierten Daten.

Prinzipien einer sicheren Konfiguration

1. Origins gegen eine Allowlist prüfen. Vergleichen Sie den eingehenden Origin mit einer festen Liste; bei Übereinstimmung genau diesen Origin spiegeln, sonst gar keinen Header senden.
2. Allow-Credentials: true nur wenn wirklich nötig — und niemals mit Wildcard oder gespiegeltem Origin kombinieren.
3. Nur benötigte Methoden und Header öffnen.
4. Dem null-Origin nicht vertrauen; manche Kontexte senden Origin: null.

So testen Sie

curl -sI -H "Origin: https://zufall-angreifer.example" https://api.ihreseite.de/daten \
  | grep -i access-control-allow

Spiegelt die Antwort Ihren gefälschten Origin und besonders access-control-allow-credentials: true, ist der Endpunkt unsicher.

Was CORS NICHT schützt

CORS ist keine Autorisierungsschicht. Es beschränkt das Lesen der Antwort, verhindert aber nicht, dass die Anfrage den Server erreicht. Serverseitige Autorisierung bleibt zwingend, und CORS allein löst CSRF nicht.

Zusammenfassung

Betrachten Sie CORS als Tor, das entscheidet, welche Seiten Ihre Daten lesen dürfen. Für öffentliche Daten ist die Wildcard in Ordnung, doch Origin-Reflection plus Credentials ist bei authentifizierten APIs fatal. Prüfen Sie Origins gegen eine Allowlist, vergeben Sie Credentials sparsam und nutzen Sie die Wildcard nur bei nicht authentifizierten Endpunkten.

Quellen: MDN: CORS, PortSwigger: CORS.

Unsicher, ob die CORS-Header Ihrer API sicher sind? Der External-Surface-Scan von CyberTestify erkennt häufige CORS-Fehlkonfigurationen aus echten Antworten.