So debuggen Sie CORS-Fehler im Browser

Apr 21, 2026 · 4 min read

Sie lösen eine Fetch-Anfrage aus, öffnen die Konsole und sehen etwas wie:

Access to fetch at ‘https://api.example.com’ from origin ‘http://localhost:3000’ has been blocked by CORS policy.

Bevor Sie anfangen, Server-Header willkürlich zu ändern, halten Sie inne. Die meisten CORS-Debugging-Aufgaben im Browser laufen darauf hinaus, zu lesen, was der Browser Ihnen bereits mitteilt — wenn Sie wissen, wo Sie suchen müssen.

Wichtigste Erkenntnisse

CORS-Fehler werden vom Browser erzwungen, nicht vom Server. Die Anfrage erreicht oft den Server; die Blockierung erfolgt bei der Antwort.
Die Browser-Konsolenmeldung ist Ihr primäres Diagnosewerkzeug — sie zeigt oft auf die fehlgeschlagene Regel oder den fehlenden Header, kann aber auch zugrunde liegende Netzwerk-, TLS- oder Policy-Probleme widerspiegeln.
Preflight-OPTIONS-Anfragen schlagen stillschweigend fehl, wenn Sie nicht danach suchen. Prüfen Sie immer den Network-Tab mit Filter “All”, um sie zu erkennen.
Nicht jeder Fehler, der wie CORS aussieht, ist tatsächlich ein CORS-Problem. Mixed Content, TLS-Fehler, Weiterleitungen und Browser-Erweiterungen können sich alle als CORS-Probleme tarnen.

Was CORS-Fehler tatsächlich bedeuten

CORS-Fehler (Cross-Origin Resource Sharing) treten auf, wenn Ihr Browser eine Cross-Origin-Anfrage blockiert, weil die Antwort des Servers nicht die richtigen Berechtigungen enthielt. Das Schlüsselwort ist Browser — die Anfrage erreicht oft den Server. Die Blockierung erfolgt auf dem Rückweg.

Ein Origin wird durch die Kombination aus Protokoll, Domain und Port definiert. http://localhost:3000 und http://localhost:4000 sind also unterschiedliche Origins, selbst auf demselben Rechner.

So debuggen Sie CORS-Fehler mit den DevTools

Öffnen Sie DevTools → Network-Tab (F12 oder Cmd+Option+I). Reproduzieren Sie die fehlgeschlagene Anfrage. Dann:

Finden Sie die fehlgeschlagene Anfrage — suchen Sie nach einem roten Eintrag oder filtern Sie nach “Fetch/XHR”.
Prüfen Sie den Console-Tab — die Fehlermeldung dort ist spezifisch. Sie sagt Ihnen, welcher Header fehlt oder nicht übereinstimmt.
Klicken Sie auf die Anfrage → Headers-Tab — untersuchen Sie sowohl die Request-Header (insbesondere Origin) als auch die Response-Header (insbesondere Access-Control-Allow-Origin).

Die Konsolenfehlermeldung ist Ihr primäres Diagnosewerkzeug. Moderne Chrome- und Firefox-Browser geben präzise Meldungen aus wie:

“No ‘Access-Control-Allow-Origin’ header is present” → der Server hat überhaupt keine CORS-Header gesendet.
“The value of ‘Access-Control-Allow-Origin’ must not be the wildcard ’*’ when credentials mode is ‘include’” → Sie verwenden credentials: 'include', aber der Server antwortete mit *.
“Method PUT is not allowed by Access-Control-Allow-Methods” → der Preflight hat Ihre HTTP-Methode abgelehnt.

Debugging von Preflight-Anfragen (OPTIONS)

Wenn Ihre Anfrage eine nicht-einfache Methode (PUT, DELETE, PATCH), Custom-Header oder einen Content-Type verwendet, der nicht zu den wenigen von der Spezifikation erlaubten gehört, sendet der Browser zuerst eine Preflight-OPTIONS-Anfrage. Wenn diese fehlschlägt, wird Ihre eigentliche Anfrage nie gesendet.

Filtern Sie im Network-Tab nach “All” und suchen Sie nach einer OPTIONS-Anfrage an dieselbe URL, die kurz vor Ihrer Hauptanfrage erscheint. Klicken Sie darauf und prüfen Sie:

Request-Header: Access-Control-Request-Method und Access-Control-Request-Headers — diese teilen dem Server mit, was die echte Anfrage benötigt.
Response-Header: Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Origin — der Server muss jeden einzelnen explizit erlauben.

Wenn die OPTIONS-Anfrage einen 4xx- oder 5xx-Statuscode zurückgibt, ist das wahrscheinlich ein serverseitiger Routing- oder Konfigurationsfehler, keine CORS-Header-Fehlkonfiguration. Beheben Sie zuerst den zugrunde liegenden Fehler.

Ist es tatsächlich ein CORS-Fehler?

Nicht jeder Fehler, der als CORS auftaucht, wird durch CORS verursacht. Häufige Fehlalarme sind:

Mixed Content — das Abrufen von http:// von einer https://-Seite wird durch die Mixed-Content-Policy des Browsers blockiert, unabhängig von CORS-Headern.
TLS-/Zertifikatfehler — ein fehlgeschlagener TLS-Handshake kann in der Konsole wie ein CORS-Fehler aussehen.
Weiterleitungen zu einem anderen Origin — wenn der Server Ihre Anfrage zu einem neuen Origin umleitet, blockiert der Browser die Anfrage. Cross-Origin-Weiterleitungen sind für CORS-Anfragen nicht erlaubt.
Browser-Erweiterungen — Datenschutz- oder Werbeblocker-Erweiterungen können Anfragen abbrechen, bevor CORS überhaupt geprüft wird.
Third-Party-Cookie-Einschränkungen — wenn Sie credentials: 'include' verwenden, können moderne Browser Cookies von Drittanbieter-Origins blockieren, selbst wenn Ihre CORS-Header völlig korrekt sind.

Um die tatsächliche Ursache zu isolieren, versuchen Sie die Anfrage in einem privaten/Inkognito-Fenster mit deaktivierten Erweiterungen.

Credentialed Requests: Eine häufige Falle

Wenn Sie fetch(url, { credentials: 'include' }) verwenden, kann der Server nicht mit Access-Control-Allow-Origin: * antworten. Er muss exakt den anfragenden Origin zurückgeben. Der Server muss außerdem Access-Control-Allow-Credentials: true in seiner Antwort einschließen. Fehlt eines von beiden, blockiert der Browser die Antwort.

Schnelle CORS-Debugging-Checkliste

Prüfung	Wonach suchen
Konsolenfehlermeldung	Exakter Header oder Regel, die fehlgeschlagen ist
OPTIONS-Anfrage vorhanden?	Preflight ausgelöst — prüfen Sie dessen Antwort
Antwort hat `Access-Control-Allow-Origin`?	Muss mit Ihrem Origin übereinstimmen oder `*` sein
Credentials verwendet?	`*` ist nicht erlaubt; exakter Origin erforderlich
4xx/5xx bei der Anfrage?	Server-Fehler — kein CORS-Problem
Mixed Content?	HTTP von HTTPS-Seite — immer blockiert

Fazit

Die Browser-Fehlermeldung, der Network-Tab und das Headers-Panel geben Ihnen alles, was Sie brauchen, um die meisten CORS-Probleme in unter fünf Minuten zu diagnostizieren. Lesen Sie die exakte Fehlermeldung, finden Sie die OPTIONS-Anfrage, falls eine existiert, vergleichen Sie, was gesendet wurde, mit dem, was erwartet wurde, und arbeiten Sie von dort aus weiter. Widerstehen Sie dem Drang, blind Access-Control-Allow-Origin: * zu Ihrem Server hinzuzufügen — verstehen Sie zuerst, was der Browser anfordert, und antworten Sie präzise.

FAQs

Nein. CORS wird vom Browser basierend auf Headern erzwungen, die der Server sendet. Das Frontend kann dies nicht überschreiben. Wenn Sie den Server nicht kontrollieren, können Sie Anfragen über einen Backend-Proxy leiten, der die korrekten Header hinzufügt, aber der browserseitige Code allein kann die Einschränkung nicht umgehen.

Postman ist kein Browser und erzwingt nicht die Same-Origin-Policy. Es sendet Anfragen direkt, ohne CORS-Header in der Antwort zu prüfen. Browser erzwingen CORS zum Schutz der Benutzer, sodass eine Anfrage, die in Postman erfolgreich ist, vom Browser dennoch blockiert werden kann, wenn der Server die erforderlichen Response-Header weglässt.

Ein Preflight wird ausgelöst, wenn die Anfrage eine andere Methode als GET, HEAD oder POST verwendet, Custom-Header enthält oder einen Content-Type setzt, der nicht application/x-www-form-urlencoded, multipart/form-data oder text/plain ist. Der Browser sendet zuerst eine OPTIONS-Anfrage, um zu bestätigen, dass der Server die eigentliche Anfrage erlaubt.

Wenn Ihre Anfrage Credentials wie Cookies oder Authorization-Header enthält, kann der Server den Wildcard-Wert nicht verwenden. Er muss mit dem exakten Origin antworten, der die Anfrage gestellt hat, und außerdem den Access-Control-Allow-Credentials-Header auf true setzen. Der Wildcard ist nur für Anfragen ohne Credentials gültig.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.