Einen einzelnen Fehler mit seinem Kontext erfassen
Halten Sie Frontend-Origin, endgültige API-URL, Methode, Zeitpunkt, Anmeldezustand und Fetch-Credentials-Modus fest. Ein abweichender Port oder ein HTTP-/HTTPS-Unterschied kann bereits relevant sein. Vermerken Sie zudem, welche Header die Anwendung ausdrücklich setzt, insbesondere Content-Type, Authorization oder eigene CSRF-Header.
Betrachten Sie einen konkreten Vorgang statt mehrere ähnliche Konsolenmeldungen zu vermischen. Bei einem erneuten Versuch kann ein Preflight aus dem Browsercache bedient werden. „Ich sehe kein OPTIONS“ bedeutet deshalb nicht automatisch, dass diese Requestart keinen Preflight benötigt.
Geben Sie Diagnosebelege nur bereinigt weiter. Cookies, Bearer-Token und sensible Nutzdaten gehören nicht in einen ungeschützten Screenshot oder HAR-Export. Für die Fehlerzuordnung reichen meist Namen der Header, ungefährliche Werte, Status und eine nicht geheime Korrelationskennung.
Schritt 1: Kam eine HTTP-Antwort zustande?
Nicht jeder fehlgeschlagene Browserfetch ist ein CORS-Konfigurationsfehler. Prüfen Sie DNS, TLS, Verbindungsfehler und ob eine HTTPS-Seite eine unzulässige HTTP-Ressource ansprechen soll. Auch die Content Security Policy des Frontends kann einen Request verhindern. Die MDN-Übersicht zu CORS-Fehlern hilft, die Browsermeldung einzuordnen.
Wenn der Browser keine passende HTTP-Antwort erreicht, behebt ein zusätzlicher Access-Control-Allow-Origin-Header dieses Verbindungsproblem nicht. Die Grundlagen finden Sie bei TLS-Zertifikaten und CSP. Prüfen Sie in der tatsächlich betroffenen Umgebung, ob der erwartete Dienst antwortet oder eine vorgeschaltete Fehlerseite erscheint.
Schritt 2: Scheitert der Preflight?
Ein Preflight ist eine OPTIONS-Anfrage mit Origin und Access-Control-Request-Method, gegebenenfalls ergänzt um Access-Control-Request-Headers. Er kündigt Methode und Headernamen an; er ist nicht schon die angemeldete Fachanfrage. Die Fetch-Spezifikation verlangt eine passende Freigabe, bevor der Browser den betreffenden Request fortsetzt.
Prüfen Sie diese Fälle:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Beobachtung in der Netzwerkansicht | Wahrscheinlicher Prüfpunkt |
|---|---|
| OPTIONS erhält 401 oder eine Loginseite | Authentifizierungsschicht verlangt Zugangsdaten für die Voranfrage; CORS vor der Fachauthentifizierung behandeln |
| OPTIONS erhält 404 oder 405 | Routing, Proxy oder Anwendung verarbeitet den Preflight nicht passend |
| OPTIONS erhält 2xx, der Browser verweigert dennoch | Origin, angeforderte Methode oder Header passen nicht zur Antwortfreigabe |
Meldung nennt Authorization | Diesen Header ausdrücklich erlauben; eine Header-Wildcard genügt dafür nicht |
| OPTIONS wird weitergeleitet | Ziel-URL, HTTPS-Umleitung, Slash-Normalisierung oder Loginweiterleitung untersuchen |
Ein 204 allein ist noch keine erfolgreiche CORS-Freigabe. Lesen Sie die Header derselben Antwort. Übertragen Sie auch nicht die Freigabe einer benachbarten Route auf den tatsächlich angefragten Pfad.
Bei Weiterleitungen ist eine direkte Anfrage an die vorgesehene API-URL meist leichter kontrollierbar. Browser- und Ablaufunterschiede machen Redirectketten zu einer zusätzlichen Fehlerquelle. Entfernen Sie deshalb keinen Authentifizierungsschutz, sondern korrigieren Sie den zuständigen Routing- oder Preflightweg.
Schritt 3: Die eigentliche Antwort separat lesen
War der Preflight erfolgreich, suchen Sie die nachfolgende API-Anfrage. Ein Header nur auf OPTIONS genügt nicht. Die API kann danach etwa mit 401, 403 oder 500 antworten, und genau diesem Fehlerpfad können CORS-Header fehlen. JavaScript sieht dann einen Netzwerkfehler, obwohl der eigentliche Serverfehler für die Diagnose entscheidend wäre.
Erlaubte Frontends sollten die vorgesehenen Fehlerantworten lesen können. Das bedeutet nicht, interne Stacktraces freizugeben. Prüfen Sie gemeinsam den Fehlervertrag und die Originfreigabe auf Erfolgs- und Fehlerpfaden.
Eine tatsächlich empfangene 401-Antwort mit korrekter CORS-Freigabe ist wiederum ein Authentifizierungsproblem, kein CORS-Problem. Unterscheiden Sie im Client den HTTP-Status von einer Fetch-Ausnahme. CORS darf auch eine fachlich abgelehnte Antwort lesbar machen; es erlaubt damit nicht die abgelehnte Operation.
Schritt 4: Originwert und doppelte Header vergleichen
Vergleichen Sie Origin und Access-Control-Allow-Origin einschließlich Schema und Port. Die erlaubte Origin enthält keinen Pfad und keinen abschließenden Slash. Mehrere Origins als Kommaliste oder zwei widersprüchliche Headerzeilen sind keine gültige Reparatur.
Besonders häufig lohnt sich die Prüfung, welche Schicht Header setzt: Anwendung, Reverse-Proxy, Gateway oder CDN. Wenn die Anwendung die richtige Origin liefert und der Proxy zusätzlich * anhängt, ist die am Browser ankommende Antwort maßgeblich. Die MDN-Fehlerreferenz zum nicht passenden Origin nennt auch mehrfache Freigabeheader als Ursache.
Ändern Sie die zuständige Schicht und prüfen Sie den gesamten Weg erneut. Eine lokale Antwort direkt vom Backend kann richtig sein, während die ausgelieferte Proxyantwort falsch bleibt. Bei dynamischer Originfreigabe gehört außerdem Vary: Origin in die Cachebetrachtung.
Schritt 5: Credentials und Cookiebedingungen trennen
Bei credentials: "include" benötigt die lesbare Cross-Origin-Antwort eine konkrete passende Origin und Access-Control-Allow-Credentials: true. Ein buchstäbliches * reicht in diesem Modus nicht. Prüfen Sie dabei die Einstellung im Client, nicht nur, ob zufällig ein Cookie in einer Aufnahme sichtbar war.
Ist die CORS-Freigabe korrekt, kann das benötigte Cookie dennoch fehlen. Prüfen Sie Domain, Pfad, Secure, SameSite, Ablauf und die Cookiehinweise des Browsers. Third-Party-Cookie-Regeln können einen Zugriff zusätzlich begrenzen. SameSite=None; Secure ist keine Garantie, dass jeder Browser jedes Cookie in jedem Kontext sendet. Die MDN-CORS-Dokumentation trennt diese Ebenen.
Ein bewusst gesetzter Authorization-Header benötigt seine eigene Preflightfreigabe. Stellen Sie den Credentials-Modus nicht wahllos um, um einen Fehler verschwinden zu lassen. Die Wahl muss zum beabsichtigten Cookie- oder Tokenmodell passen.
Drei Änderungen, die den Fehler nur verdecken
mode: "no-cors" macht eine geschützte API-Antwort nicht regulär lesbar. Die Antwort kann für JavaScript opaque bleiben; Status, Header und Inhalt stehen dann nicht wie bei einer normalen CORS-Antwort zur Verfügung. Das ist keine Lösung für einen JSON-Client.
Access-Control-Allow-Origin als eigener Requestheader erteilt ebenfalls keine Freigabe. Diese Entscheidung trifft der Server in der Antwort. Ein zusätzlicher ungewöhnlicher Requestheader kann den Ablauf sogar weiter verändern.
Eine Browsererweiterung oder abgeschaltete Websicherheit erzeugt schließlich eine andere Umgebung als die Ihrer Benutzer. Verwenden Sie sie nicht als Abnahme. Die Sollkonfiguration beschreibt CORS für APIs.
Den Erfolg belegen und Änderungen begrenzen
Nach der Korrektur prüfen Sie denselben Vorgang mit derselben Origin und Clientkonfiguration erneut. Ergänzen Sie einen eigenen nicht erlaubten Origin sowie ausgeloggte und fachlich abgelehnte Fälle. Dokumentieren Sie, ob die Voranfrage, die eigentliche Antwort und das Lesen durch JavaScript jeweils das erwartete Ergebnis liefern. Serverrechte müssen unabhängig davon weiterhin greifen.
Ändern Sie möglichst eine zuständige Regel pro Diagnosehypothese und sichern Sie die vorige Konfiguration. Bei Nebenwirkungen nehmen Sie diese konkrete Änderung zurück; erweitern Sie nicht vorsorglich alle Origins, Methoden und Header. Berücksichtigen Sie gespeicherte Preflightfreigaben bei der Wiederholungsprobe.
Der öffentliche API Security Check kann Antwortheader als zusätzliche Momentaufnahme zeigen. Er reproduziert weder Ihre Cookies noch den konkreten Browserfehler. Die passende Reparatur folgt deshalb dem beobachteten Ablauf. Quellenstand: 27. September 2026.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.