CORS Fehler beheben: Fehlender Allow Origin Header

Wie behebt man einen CORS Fehler?

Ein CORS Fehler bedeutet, dass der Browser die Antwort einer anderen Herkunft nicht an Ihren JavaScript Code weitergibt, weil der Server keine Freigabe Header sendet. Sie beheben ihn auf dem Server: Fügen Sie der API Antwort den passenden Access-Control-Allow-Origin Header hinzu und beantworten Sie die Preflight Anfrage (OPTIONS) erfolgreich.

Eine rote Meldung in der Konsole wirkt dringend, die Ursache ist aber meist klein. Oft fehlt nur ein Header oder eine Adresse ist falsch geschrieben. Dieser Leitfaden geht die Prüfungen von der wahrscheinlichsten bis zur unwahrscheinlichsten Ursache durch.

Deshalb halten wir den Umfang bewusst eng. Wenn Ihr lokaler Server gar nicht antwortet, lesen Sie zuerst unsere Anleitung zu localhost Verbindung abgelehnt. Dort liegt ein Netzwerkproblem vor, kein CORS Problem.

Was ist die schnelle Lösung für einen CORS Fehler, Schritt für Schritt?

Prüfen Sie zunächst, ob es wirklich CORS ist, denn mehrere andere Fehler sehen ähnlich aus. Gehen Sie dann in dieser Reihenfolge vor.

1. Öffnen Sie in den Entwicklertools des Browsers den Reiter Netzwerk und suchen Sie die fehlgeschlagene Anfrage.
2. Prüfen Sie, ob die fehlgeschlagene Anfrage der Preflight (OPTIONS) oder die eigentliche Anfrage ist.
3. Suchen Sie in der Antwort den Header Access-Control-Allow-Origin.
4. Vergleichen Sie seinen Wert Zeichen für Zeichen mit der Herkunft in Ihrer Adressleiste.
5. Prüfen Sie bei einem Preflight auch Access-Control-Allow-Methods und Access-Control-Allow-Headers.
6. Senden Sie Cookies oder einen Authorization Header, ersetzen Sie den Platzhalter (*) durch eine konkrete Herkunft und ergänzen Sie Access-Control-Allow-Credentials.
7. Korrigieren Sie den Server, leeren Sie Caches und wiederholen Sie die Anfrage.

Diese sieben Schritte lösen die meisten Fälle. Die Reihenfolge ist Absicht, denn der Reiter Netzwerk liefert die Fakten. Der Reiter Netzwerk zeigt die Fakten, die Konsole fasst sie nur zusammen. Deshalb sollten Sie die ersten beiden Schritte nicht überspringen.

Warum entsteht ein CORS Fehler, und was ist die Same Origin Policy?

Browser setzen standardmäßig die Same Origin Policy durch. Sie verhindert, dass Code einer Seite Antworten einer anderen Herkunft liest. Dadurch kann eine schädliche Seite Ihre angemeldete Sitzung nicht nutzen, um Daten einer anderen Seite auszulesen.

CORS (Cross Origin Resource Sharing) ist eine kontrollierte Ausnahme von dieser Regel. Der Server teilt per Header mit, welche Herkünfte seine Antworten lesen dürfen. Dann prüft der Browser diese Header und hält die Antwort zurück, wenn sie nicht passen.

Ein Detail überrascht jedoch viele Entwickler. Die Anfrage erreicht den Server oft, und der Server antwortet. Allerdings hindert der Browser Ihren Code daran, die Antwort zu lesen. Deshalb sehen Sie die Anfrage im Serverlog, während die Konsole einen Fehler meldet.

Die vollständigen Regeln finden Sie im MDN Leitfaden zu CORS und im WHATWG Fetch Standard.

Was ist eine Herkunft (Origin), und welche Adressen gelten als verschieden?

Eine Herkunft besteht aus drei Teilen: Schema, Host und Port. Unterscheidet sich einer davon, betrachtet der Browser die beiden Adressen als verschiedene Herkünfte. Pfad und Query String zählen dagegen nicht dazu.

• https://app.example.com und http://app.example.com sind verschieden, weil das Schema abweicht.
• https://app.example.com und https://api.example.com sind verschieden, weil der Host abweicht.
• https://example.com und https://example.com:8443 sind verschieden, weil der Port abweicht.
• https://example.com/a und https://example.com/b haben dieselbe Herkunft.

Zum Beispiel läuft Ihr Frontend in der Entwicklung auf einem Port und Ihre API auf einem anderen. Selbst auf demselben Rechner sind das verschiedene Herkünfte, also greift CORS.

Außerdem gelten localhost und 127.0.0.1 als verschiedene Hosts. Erlauben Sie die eine Schreibweise im Header, rufen aber über die andere auf, erhalten Sie den Fehler.

Kann man einen CORS Fehler im Browser oder Client abschalten?

Nein, die richtige und dauerhafte Lösung liegt nicht im Client. Der Server trifft die CORS Entscheidung über Header, und keine Fetch Option kann sie überstimmen. Fehlt der Header in der Antwort, hält der Browser die Antwort trotzdem zurück.

Dennoch empfehlen viele Beiträge Browser Erweiterungen oder Startoptionen, die Websicherheit ausschalten. Das empfehlen wir nicht, denn sie wirken nur auf Ihrem eigenen Rechner, sie lösen das Problem nicht für Ihre Nutzer, und sie öffnen Ihren Browser für echte Angriffe.

Auch der Fetch Modus no-cors ist keine Lösung. Die Anfrage geht zwar raus, aber die Antwort wird undurchsichtig (opaque), sodass Ihr Code sie nicht lesen kann. Der Fehler verstummt also, die Daten bleiben dennoch unerreichbar.

Kurz gesagt beheben Sie das Problem an einer von drei Stellen: auf dem API Server, im Reverse Proxy davor oder in einem Proxy, den Sie während der Entwicklung selbst steuern. Alle drei erklären wir unten.

Was sind einfache Anfragen und Preflight Anfragen?

Der Browser schickt manche Anfragen direkt los. Das nennt man einfache Anfragen. Bei allen anderen sendet er zuerst eine OPTIONS Anfrage, den Preflight, und fragt den Server um Erlaubnis. Lautet die Antwort nein, sendet der Browser die eigentliche Anfrage nie.

Eine einfache Anfrage nutzt GET, HEAD oder POST und nur sichere Header. Bei POST muss der Inhaltstyp Formulardaten oder einfacher Text sein. Die genauen Regeln listet der MDN Leitfaden zu CORS.

In der Praxis lösen diese Fälle einen Preflight aus:

• Eine POST Anfrage mit dem Inhaltstyp application/json.
• Methoden wie PUT, PATCH oder DELETE.
• Eigene Header wie Authorization.

Das erklärt also die häufige Klage, GET funktioniere, POST aber nicht. Meist ist dann der Preflight gescheitert, nicht das POST selbst.

Zudem trägt der Preflight keinen Body, und Ihr eigener Code sieht ihn nie. Denn der Browser erzeugt ihn automatisch. Hat Ihre App also keinen Handler für OPTIONS, trifft die Anfrage auf eine unerwartete Antwort.

Welche CORS Antwort Header brauchen Sie?

Der Server sendet diese Header mit seiner Antwort. Jeder hat eine andere Aufgabe, daher sollten Sie sie getrennt betrachten.

• Access-Control-Allow-Origin nennt die Herkunft, die die Antwort lesen darf. Es steht dort also eine Herkunft oder ein Platzhalter.
• Access-Control-Allow-Methods listet in der Preflight Antwort die erlaubten Methoden auf.
• Access-Control-Allow-Headers listet die Anfrage Header auf, die die echte Anfrage nutzen darf.
• Access-Control-Allow-Credentials erlaubt Anfragen mit Cookies oder Anmeldedaten. Der einzige gültige Wert lautet true.
• Vary: Origin sagt Caches, dass die Antwort je nach Herkunft variiert.

Für viele APIs genügt dieser kurze Satz in der Preflight Antwort:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Vary: Origin

Muss Ihr Frontend eigene Antwort Header lesen, nutzen Sie zusätzlich Access-Control-Expose-Headers. Header Namen unterscheiden nicht zwischen Groß und Kleinschreibung, Werte aber schon. Schreiben Sie die Herkunft also klein. Details finden Sie in der MDN Referenz zum Allow Origin Header.

Warum funktioniert der Platzhalter (*) nicht mit Anmeldedaten?

Trägt eine Anfrage Cookies, HTTP Authentifizierung oder Client Zertifikate, lehnt der Browser Access-Control-Allow-Origin: * ab. Er verlangt stattdessen eine einzelne, konkrete Herkunft.

Nutzen Sie credentials: "include" bei Fetch, brauchen Sie diese drei Dinge zusammen:

1. Die Antwort nennt in Access-Control-Allow-Origin genau eine konkrete Herkunft.
2. Die Antwort enthält Access-Control-Allow-Credentials: true.
3. Eine Preflight Antwort listet konkrete Methoden und Header, keine Platzhalter.

Viele Teams wollen hier mehrere Herkünfte unterstützen und kopieren daher den eingehenden Origin Wert in die Antwort. Das funktioniert allerdings nur sicher mit einer Erlaubnisliste. Vergleichen Sie den Wert zuerst mit einer bekannten Erlaubnisliste, bevor Sie ihn zurückgeben.

Zur Sitzungs und Token Seite dieses Themas hilft unsere Anleitung zu JWT.

Warum scheitert die Preflight Anfrage (OPTIONS)?

Ein scheiternder Preflight ist die häufigste Ursache hinter der Klage, GET gehe, POST aber nicht. Ihr Server kennt OPTIONS womöglich nicht oder schickt diese Anfrage durch eine Authentifizierungsschicht.

Prüfen Sie daher die Ursachen in dieser Reihenfolge, von der wahrscheinlichsten zur unwahrscheinlichsten:

1. Der Server antwortet auf OPTIONS mit 404 oder 405. Ergänzen Sie die Methode in Ihrer Routenliste.
2. Eine Authentifizierungs Middleware weist den Preflight ab, weil er keinen Authorization Header trägt. Der Browser sendet im Preflight nie Anmeldedaten, also beantworten Sie OPTIONS vor der Authentifizierung.
3. Der Preflight liefert keinen Erfolgsstatus (2xx).
4. In Access-Control-Allow-Headers fehlt ein Header, den Ihre Anfrage nutzt.
5. Der Preflight landet auf einer Weiterleitung. Browser folgen bei einem Preflight keiner Weiterleitung.

Im Reiter Netzwerk erscheint die OPTIONS Anfrage nämlich als eigene Zeile. Lesen Sie zuerst diese Zeile samt Statuscode und Antwort Headern. Die Prüfung dauert Sekunden, also spart sie oft Stunden.

Zum Beispiel liefert eine Middleware, die jede Route umschließt, für OPTIONS den Status 401. Der Browser zeigt dann einen CORS Fehler, aber die eigentliche Ursache ist die Reihenfolge der Middleware.

Welche CORS Fehler passieren am häufigsten?

In der Praxis sehen wir vor allem kleine Schreibunterschiede, denn Tippfehler sind häufig. Der Browser vergleicht Werte exakt und hat keine Toleranz.

• Falsche Herkunft: Der Header nennt https://example.com, die Seite ruft aber von https://www.example.com auf.
• Schrägstrich am Ende: Sie schreiben https://app.example.com/ in den Header, obwohl eine Herkunft keinen Schrägstrich am Ende hat.
• http gegen https: Entwicklung nutzt http, Produktion nutzt https, und Ihre Erlaubnisliste deckt nur eines ab.
• Fehlender Port: In der lokalen Entwicklung gehört der Port zur Herkunft.
• Doppelter Header: Sowohl die App als auch der Reverse Proxy setzen den Header, und der Browser lehnt den doppelten Wert ab.
• Mehrere Herkünfte in einem Wert: Sie schreiben zwei Adressen mit Komma, aber der Header akzeptiert nur eine Herkunft.

All das erkennen Sie, wenn Sie im Reiter Netzwerk die Antwort Header neben die Adressleiste legen.

Beachten Sie, dass keiner dieser Fehler Spuren im Server hinterlässt. Der Server schweigt dann, und nur der Browser meldet sich. Prüfen Sie den Header Wert deshalb für jede neue Umgebung von Hand.

Kann eine Weiterleitung einen CORS Fehler verursachen?

Ja. Liefert Ihre API Adresse eine Weiterleitung, etwa von http auf https oder von einem Pfad ohne Schrägstrich auf einen mit Schrägstrich, kann die CORS Prüfung brechen. Ein Preflight folgt nie einer Weiterleitung.

Ein typisches Beispielszenario sieht so aus. Das Frontend ruft einen Pfad ohne Schrägstrich auf. Dann antwortet der Server mit einer 301 Weiterleitung auf die Variante mit Schrägstrich. Weil diese Weiterleitung keinen CORS Header trägt, meldet der Browser einen Fehler.

Die Lösung ist einfach: Rufen Sie die endgültige Adresse direkt auf. So steht keine Weiterleitung dazwischen, und alle Header kommen in einer Antwort an.

Weiterleitungsketten sehen Sie mit unserem kostenlosen Redirect Checker. Fügen Sie die Adresse ein und verfolgen Sie, wohin sie Schritt für Schritt führt.

Warum fehlt der CORS Header bei 4xx und 5xx Antworten?

Viele Frameworks setzen CORS Header nur bei erfolgreichen Antworten. Liefert der Server 401, 404 oder 500, läuft die Middleware womöglich nicht, und der Header fehlt. Der Browser zeigt dann einen CORS Fehler statt des echten Fehlers.

Das schickt Sie also in die falsche Richtung. In der Konsole steht eine CORS Warnung, doch das eigentliche Problem ist ein Serverfehler. Zum Beispiel ist die Authentifizierung fehlgeschlagen, und der Server hat 401 geliefert.

Für eine saubere Diagnose testen Sie die Anfrage außerhalb des Browsers mit einem kurzen Befehl:

curl -i -X OPTIONS https://api.example.com/orders \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: POST"

Lesen Sie dann Statuscode und Header. Lautet der Status 5xx, beheben Sie zuerst den Serverfehler, denn das CORS Symptom ist nachrangig. Die allgemeine Logik von Serverfehlern erklärt unsere Anleitung zum 500 Internal Server Error.

Wie lesen Sie eine CORS Diagnosetabelle nach Fehlerart?

Browser formulieren Meldungen unterschiedlich und ändern sie mit der Zeit. Die Tabelle unten zeigt deshalb die Bedeutung ähnlicher Warnungen, keinen exakten Wortlaut. Den genauen Text finden Sie auf der MDN Seite zu CORS Fehlern.

Lesen Sie bei der Tabelle zuerst den Konsolentext und dann die Antwort Header im Reiter Netzwerk. Zusammen zeigen sie die Ursache fast immer.

Wie umgehen Sie einen CORS Fehler in der Entwicklung mit einem Proxy?

Hat Ihr Entwicklungsserver eine Proxy Funktion, ist das der sauberste Weg. Das Frontend ruft seine eigene Herkunft auf, und der Entwicklungsserver leitet die Anfrage an die API weiter. Aus Sicht des Browsers ist der Aufruf dann gleichen Ursprungs, also greift CORS gar nicht.

Der große Vorteil: Sie schwächen die Browsersicherheit nie ab. Außerdem ähnelt das Setup der Produktion, somit gibt es weniger Überraschungen. Die meisten modernen Entwicklungswerkzeuge erlauben einen pfadbasierten Proxy mit wenigen Zeilen Konfiguration. Der Name der Einstellung unterscheidet sich je nach Werkzeug, daher lesen Sie dessen offizielle Dokumentation.

Diese Lösung gilt allerdings nur für die Entwicklung. Für die Produktion wählen Sie einen von zwei Wegen:

• Betreiben Sie die API hinter derselben Herkunft wie das Frontend, mit einem Reverse Proxy, der nach Pfad weiterleitet.
• Lassen Sie die API auf einem eigenen Host und schreiben Sie die CORS Header korrekt.

Die erste Variante beseitigt den größten Teil des CORS Bedarfs. Die Idee erklären wir in unserer Anleitung zum Nginx Reverse Proxy.

Ein Proxy verringert zudem Cookie Probleme. Weil die Anfrage an dieselbe Herkunft geht, reisen Cookies normal mit. Deshalb wählen viele Teams diesen Weg in der Entwicklung.

Wo setzen Sie CORS Header hinter einem Reverse Proxy oder CDN?

Verwalten Sie die Header an genau einer Stelle. Entscheiden Sie einmal, ob die App, der Reverse Proxy oder das CDN sie setzt, und schalten Sie die anderen ab. Sonst geraten Sie in das Problem doppelter Header.

Setzen Sie sie im Anwendungscode, dann versionieren Sie die Regeln gemeinsam mit dem Code. Setzen Sie sie im Reverse Proxy, haben Sie eine Einstellung für alle Dienste. Cacht ein CDN Antworten, behalten Sie Vary: Origin bei. Ohne diesen Header kann eine Antwort für eine Herkunft bei einer anderen landen.

Ein Beispielszenario: Ein Team setzt den Header in der App und zusätzlich im Reverse Proxy. Die Antwort zeigt Access-Control-Allow-Origin zweimal, und der Browser lehnt sie ab. Die Lösung besteht darin, einen der beiden zu entfernen.

Achten Sie außerdem auf eine häufige Falle in Hosting Oberflächen. Auf CDN oder Hosting Ebene kann es eine fertige CORS Option geben, während Ihre App einen eigenen Header setzt. Lesen Sie die rohen Antwort Header, um zu sehen, welche Schicht sie geschrieben hat.

Die Syntax der Konfiguration unterscheidet sich je nach Server, daher lesen Sie die offizielle Dokumentation und testen die Änderung zuerst in einer Staging Umgebung.

Wie diagnostizieren Sie einen CORS Fehler mit den Entwicklertools?

Die Konsole sagt Ihnen, was passiert ist, und der Reiter Netzwerk zeigt, warum. Nutzen Sie beide zusammen.

1. Lesen Sie die Konsolenmeldung und notieren Sie, welcher Header fehlt oder falsch ist.
2. Öffnen Sie den Reiter Netzwerk, wählen Sie die fehlgeschlagene Anfrage aus und lesen Sie die Antwort Header.
3. Suchen Sie den Anfrage Header Origin. Das ist die Herkunft, die der Server gesehen hat.
4. Vergleichen Sie ihn mit Access-Control-Allow-Origin in der Antwort.
5. Prüfen Sie bei einem Preflight die OPTIONS Zeile auf dieselbe Weise.

Sehen Sie keinen Fehler, die Antwort wirkt aber leer, schauen Sie womöglich auf eine veraltete Antwort aus dem Cache. Deaktivieren Sie dann den Cache und versuchen Sie es erneut.

Haben Sie die Seite aus dem Dateisystem geöffnet, dann lautet die Herkunft "null", und viele Server lehnen sie ab. Starten Sie stattdessen einen kleinen lokalen Server.

Verwechselt man Cookies und SameSite Einstellungen mit CORS?

Ja, das passiert oft. Beide können das Symptom "Anmeldedaten werden nicht gesendet" erzeugen, die Ursachen unterscheiden sich aber. CORS entscheidet, ob Ihr Code die Antwort lesen darf. Die Cookie Attribute und Anfrage Optionen entscheiden, ob das Cookie mit der Anfrage reist.

Prüfen Sie in dieser Reihenfolge. Zunächst muss die Anfrage die Option credentials aktivieren. Dann prüfen Sie, ob der Server Access-Control-Allow-Credentials: true sendet. Schließlich kontrollieren Sie, ob die Attribute SameSite und Secure des Cookies zu seitenübergreifenden Anfragen passen.

Reist das Cookie nicht mit, bleiben Sie also nicht am CORS Text hängen. Schauen Sie im Reiter Netzwerk, ob die Anfrage einen Cookie Header trägt. Wenn nicht, liegt das Problem auf der Cookie Seite.

Das genaue Verhalten kann sich zwischen Browserversionen unterscheiden. Prüfen Sie die aktuellen Regeln im MDN Leitfaden zu CORS und in der Dokumentation Ihres Browsers.

Sieht ein CORS Fehler bei Fetch, XMLHttpRequest und axios unterschiedlich aus?

Nein, die Regel ist dieselbe. Nur das Aussehen des Fehlers ändert sich. Fetch lehnt meist mit einem vagen Netzwerkfehler ab, und die Details stehen nur in der Konsole. Bei XMLHttpRequest oder axios sehen Sie im Fehlerobjekt typischerweise eine allgemeine "Network Error" Meldung.

Ihr catch Block verrät Ihnen die Ursache also nicht, weil JavaScript sie nicht sieht. JavaScript kann CORS Details nicht lesen, denn der Browser verbirgt sie aus Sicherheitsgründen vor der Seite. Konsole und Reiter Netzwerk bleiben Ihre besten Quellen.

Ein praktischer Tipp: Prüfen Sie, bevor Sie dem Nutzer einen Fehler zeigen, ob überhaupt ein Statuscode ankam. Kam keiner an, haben Sie wahrscheinlich CORS oder ein Netzwerkproblem. Kam einer an, liegt die Ursache in der Anwendungsschicht.

Die CORS Regel ändert sich auch zwischen REST und GraphQL nicht. Den Unterschied der beiden Stile erklärt unsere Anleitung zu GraphQL und REST.

Cacht der Browser einen Preflight, und warum erscheinen Änderungen nicht sofort?

Ja, Browser dürfen ein Preflight Ergebnis eine Weile zwischenspeichern. Der Server schlägt die Dauer mit Access-Control-Max-Age vor, und jeder Browser wendet eine eigene Obergrenze an. Die aktuellen Grenzen finden Sie in der Dokumentation.

Das hat allerdings einen Nebeneffekt. Sie korrigieren den Header auf dem Server, doch der Browser nutzt weiter das alte Preflight Ergebnis. Dann denken Sie, die Korrektur habe nichts gebracht.

Probieren Sie zunächst Folgendes: Deaktivieren Sie in den Entwicklertools den Cache und laden Sie die Seite hart neu. Wiederholen Sie die Anfrage danach in einem privaten Fenster. Ändert sich das Ergebnis, lag es am Cache.

In der Produktion vermeiden Sie daher sehr lange Cache Zeiten. Eine falsche Einstellung bleibt sonst in den Browsern Ihrer Nutzer, bis sie abläuft.

Beispielszenario: Wie läuft die Diagnose, wenn Frontend und API auf verschiedenen Hosts liegen?

Dies ist ein Beispielszenario und kein echter Kundenfall. Zunächst: Das Frontend läuft auf https://app.example.com und die API auf https://api.example.com. Die Anmeldeseite lädt Daten per GET, aber das Registrierungsformular scheitert bei POST.

1. Zunächst warnt die Konsole, dass der Preflight gescheitert ist.
2. Dann zeigt der Reiter Netzwerk die OPTIONS Zeile mit Status 401.
3. Denn die Authentifizierungsschicht der API versucht, auch OPTIONS zu authentifizieren.
4. Sie ordnen die Middleware um, sodass OPTIONS vor der Authentifizierung eine 2xx Antwort erhält.
5. Sie ergänzen einen Access-Control-Allow-Origin Header, der die Herkunft konkret nennt.
6. Schließlich testen Sie das Registrierungsformular erneut.

In diesem Beispiel lag das Problem nicht an der CORS Einstellung, sondern an der Reihenfolge der Middleware. Einen Header zu schreiben genügt also nicht; Sie müssen verstehen, welche Schicht die Anfrage zuerst sieht.

Wie verhindern Sie einen CORS Fehler dauerhaft?

Eine dauerhafte Lösung verlegt die CORS Einrichtung von festen Werten in die Konfiguration. So bekommen Entwicklung, Staging und Produktion jeweils eine eigene Erlaubnisliste. Diese Checkliste hilft:

• Halten Sie erlaubte Herkünfte in einer Liste und definieren Sie je eine pro Umgebung.
• Schreiben Sie den eingehenden Origin nur dann in die Antwort, wenn er in der Liste steht.
• Beantworten Sie OPTIONS vor der Authentifizierung.
• Setzen Sie CORS Header auch bei Fehlerantworten.
• Behalten Sie Vary: Origin auf jeder Cache Schicht bei.
• Erzeugen Sie den Header nur in einer Schicht.
• Führen Sie nach jedem Deployment einen automatischen Smoke Test aus, der den Preflight prüft.

Ergänzen Sie außerdem einen Integrationstest, wenn der Fehler immer wiederkehrt. Der Test sendet eine OPTIONS Anfrage von einer anderen Herkunft und prüft die Header. Dann erkennen Sie die nächste Regression, bevor sie die Produktion erreicht.

Ist CORS eine Sicherheitsmaßnahme oder nur ein Hindernis?

Zunächst gilt: CORS ist kein Autorisierungssystem. Es hindert Anfragen nämlich nicht daran, Ihren Server zu erreichen. Es steuert nur, ob der Browser die Antwort an den Seitencode weitergibt. Ein Angreifer kann dieselbe Anfrage mühelos außerhalb eines Browsers senden.

Eine CORS Einstellung ersetzt daher nie die API Sicherheit. Sie brauchen weiterhin Authentifizierung, Autorisierung und Eingabeprüfung. Häufige Risiken im Web beschreibt unsere Anleitung zu den OWASP Top 10.

Andererseits schafft eine zu breite Richtlinie echtes Risiko. Erlauben Sie jede Herkunft und aktivieren Anmeldedaten, können fremde Seiten im Namen Ihres Nutzers Daten lesen. Halten Sie die Erlaubnisliste deshalb eng.

Sind Sie neu beim Thema, erklärt unsere Anleitung Was ist eine API die Grundlagen.

Wie unterstützen Talha Aslan und Team Sie dabei?

Konkret arbeitet unser Team an Webanwendungen, API Anbindungen und Auslieferungs Infrastruktur. CORS Probleme tauchen meist auf, wenn verschiedene Teams Frontend und Server schreiben oder ein Projekt auf eine neue Domain umzieht.

Erstreckt sich Ihr Projekt über mehrere Hosts, einen Reverse Proxy und ein CDN, geht die gemeinsame Diagnose schneller. Je nach Umfang können Sie für unsere individuelle Softwareentwicklung ein Angebot anfordern.

Dieser Artikel ist keine Rechts oder Sicherheitsberatung. Für werkzeugspezifische Details lesen Sie immer die offizielle Dokumentation des jeweiligen Werkzeugs.