CORS für APIs richtig konfigurieren

Zuerst den tatsächlichen Browserbedarf klären

Ein Origin besteht aus Schema, Host und Port. https://app.example.com und https://api.example.com sind verschiedene Origins; ebenso zwei unterschiedliche Ports desselben Hosts. Der Pfad gehört nicht zum Origin. Für Browserzugriffe innerhalb desselben Origins ist keine zusätzliche CORS-Freigabe nötig. Reine Serverintegrationen brauchen sie ebenfalls nicht.

Notieren Sie für jeden Browserclient seine echte Origin, die benötigten API-Routen, Methoden und Requestheader. Ergänzen Sie, ob Antworten öffentlich oder benutzerbezogen sind. Diese kleine Liste ist der Ausgangspunkt der Konfiguration. Eine vergessene Testdomain sollte nicht dazu führen, beliebige Origins ungeprüft zu spiegeln.

Die grundlegende Protokollbeschreibung steht im Fetch Standard, Abschnitt 3.3. Die getrennten Browsermaßnahmen COOP, COEP und CORP behandelt der Webratgeber zu Cross-Origin-Headern; sie ersetzen diese API-Freigabe nicht.

Öffentliche und credentialbezogene Antworten unterscheiden

Für einen bewusst allgemein lesbaren Datenendpunkt kann folgende Antwortfreigabe passen:

Access-Control-Allow-Origin: *

Das ist ein synthetischer Headerausschnitt, keine vollständige Serverkonfiguration. Die Wildcard allein beweist keinen Sicherheitsfehler. Klären Sie vielmehr, ob die Antwort tatsächlich für beliebige Browserorigins bestimmt ist und keine unbeabsichtigt geschützten Inhalte enthält.

Soll ein bekanntes Frontend Antworten mit dem Fetch-Modus credentials: "include" lesen, ist eine konkrete Freigabe nötig, beispielsweise:

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

Der Wert true ist hier genau so geschrieben. Die Kombination aus include und Access-Control-Allow-Origin: * funktioniert nicht – auch wenn in einer einzelnen Anfrage gerade kein Cookie vorhanden ist. Maßgeblich ist der Credentials-Modus. Gleichzeitig garantiert include nicht, dass ein Cookie gesendet wird: Cookieattribute und Browserrichtlinien gelten zusätzlich. Die Kombinationen zeigt Fetch, Abschnitt 3.3.5.

Verwechseln Sie diesen Modus nicht mit einem ausdrücklich im Anwendungscode gesetzten Authorization-Header. Dessen CORS-Freigabe erfolgt über die zugelassenen Requestheader. Ein manuell gesetztes Bearer-Token bedeutet nicht automatisch, dass credentials: "include" für den Aufruf benötigt wird.

Origins aus einer festen Vertrauensentscheidung freigeben

Access-Control-Allow-Origin enthält eine passende Origin oder die Wildcard, keine kommaseparierte Liste mehrerer Websites. Wenn mehrere Frontends zugelassen sind, vergleicht der Server die eingehende Origin mit einer gepflegten Allowlist und gibt für einen erlaubten Fall genau diese Origin zurück.

Prüfen Sie vollständige Origins. Eine Teilstringsuche nach example.com kann unerwünschte Namen einschließen. Ein pauschales Spiegeln von $http_origin beziehungsweise origin: true enthält allein keine Vertrauensentscheidung. Auch null ist keine Bezeichnung für „kein Risiko“: Verschiedene Dokumentkontexte können eine so serialisierte Origin haben. Für eine gewöhnliche geschützte Browser-API gehört sie nicht vorsorglich auf die Liste.

Eine vertrauenswürdige Origin ist außerdem eine dauerhafte Betriebsverantwortung. Wenn Sie eine ehemalige Vorschau- oder Partnerdomain nicht mehr kontrollieren, überprüfen und entfernen Sie deren Freigabe. Für die tatsächlichen Datenrechte bleibt die Anwendung zuständig.

Preflight und eigentliche Antwort getrennt konfigurieren

Ein JSON-Request mit Content-Type: application/json, ein eigener Requestheader oder bestimmte Methoden können einen Preflight auslösen. Der Browser sendet dafür OPTIONS mit Origin, beabsichtigter Methode und gegebenenfalls Headernamen. Er schickt dabei nicht bereits das Bearer-Token oder Sitzungscookie der späteren Anfrage mit.

Für einen eingegrenzten JSON-Client könnte eine synthetische Preflightantwort so aussehen:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, X-CSRF-Token
Vary: Origin

Dieses Beispiel nimmt cookiebezogene Requests mit einem CSRF-Header an. Benötigt Ihre API stattdessen Authorization, muss dieser Header ausdrücklich zugelassen werden. Eine Wildcard bei Access-Control-Allow-Headers deckt Authorization nicht ab. Antworten mit Credentials erfordern auch bei den anderen Freigabelisten eine passende ausdrückliche Konfiguration. Siehe Fetch: Requestheader und Preflightprüfung.

Der erfolgreiche Preflight authentifiziert keinen Benutzer. Nach ihm muss die eigentliche API-Anfrage weiterhin alle Zugangs-, Rechte- und Eingabeprüfungen bestehen. Die eigentliche Antwort braucht ebenfalls die passende Origin- und gegebenenfalls Credentials-Freigabe. Das gilt auch für Fehlerantworten, die der erlaubte Client auswerten soll. Eine Liste erlaubter Methoden im CORS-Header implementiert zudem keine serverseitige Methodensperre.

Caches und auslesbare Antwortheader berücksichtigen

Wenn die Originfreigabe von der Anfrage abhängt, muss der Cache diese Unterscheidung berücksichtigen. Vary: Origin kennzeichnet die entsprechende Antwortvariante. Erhalten Sie vorhandene Vary-Werte statt sie zu überschreiben. Eine feste Wildcardantwort braucht diesen Unterschied allein wegen CORS nicht. Die Grundlage erläutert Fetch: CORS und HTTP-Caches.

Das schützt noch nicht vor falschem Caching benutzerbezogener Daten. Deren Speicherregeln sind eine zusätzliche Entscheidung; der Cache-Control-Ratgeber liefert die Grundlage. Ein CORS-Header trennt keine Benutzersitzungen im gemeinsamen Cache.

Wenn JavaScript einen eigenen Antwortheader wie X-Request-ID lesen soll, benötigt es gegebenenfalls Access-Control-Expose-Headers: X-Request-ID. Das ist eine andere Liste als Access-Control-Allow-Headers für ausgehende Requestheader. Das Freigeben des Namens macht den Inhalt nicht automatisch geeignet; auch eine Korrelationskennung sollte keine vertraulichen Daten enthalten.

Eine Änderung mit erlaubten und unerlaubten Fällen prüfen

Testen Sie in einer eigenen Umgebung den regulären Browserclient, einen eigenen zweiten nicht erlaubten Origin, einen passenden Preflight und die eigentliche Antwort. Nehmen Sie Erfolgs-, Anmelde- und fachliche Fehlerpfade auf. Bei Cookies prüfen Sie sowohl eingeloggte als auch ausgeloggte Zustände und die tatsächlich unterstützten Browserbedingungen.

Ein HTTP-Werkzeug kann die gelieferten Header dokumentieren. Ob Browsercode eine Antwort lesen kann und welche Cookies der Browser sendet, muss im Browserablauf geprüft werden. Lassen Sie die serverseitige Autorisierung auch mit einem Client ohne Origin prüfen; sie darf nicht von der CORS-Freigabe abhängen.

Führen Sie Änderungen zunächst für klar bekannte Clients ein. Halten Sie die vorherige Allowlist und Konfiguration zur Rücknahme bereit. Bei versehentlich zu weiter Freigabe schließen Sie die betroffenen Origins und untersuchen die betroffenen Antworten; ein Headerfund allein beweist aber noch keinen Datenabfluss. Prüfen Sie nach dem Rückweg erneut, auch unter Berücksichtigung zwischengespeicherter Preflights.

Was ein öffentlicher CORS-Befund aussagt

Der API Security Check beobachtet ausgewählte öffentliche GET-Antworten mit Test-Origins und ergänzende OPTIONS-Angaben. Er sendet keine Benutzercredentials und führt keinen angemeldeten Browserablauf aus. Eine großzügige Freigabe ist daher ein konkreter Konfigurationshinweis; ob geschützte Daten lesbar sind, hängt zusätzlich von Antwortinhalt, Authentifizierung und Browserbedingungen ab.

Für die Umsetzung führen die Anleitungen zu nginx oder Express weiter. Wenn die Konfiguration bereits steht, hilft die CORS-Fehlerdiagnose. Quellenstand: 27. September 2026.

Passende nächste Schritte