Die Konsole meldet einen CORS-Fehler und die Anfrage scheitert? Nicht der Browser ist schuld — der Server muss den Zugriff von deiner Herkunft erlauben.
Aufwand:
ca. 25 Min.
Das Symptom
Eine Webseite oder Web-App soll Daten von einer Programmierschnittstelle (API) laden,
aber in der Browser-Konsole erscheint rot ein Fehler mit dem Wortlaut blocked by CORS policy oder No 'Access-Control-Allow-Origin' header. Dieselbe Anfrage
funktioniert von einem Kommandozeilen-Werkzeug aus einwandfrei.
Die „Layer 8“-Wahrheit
CORS wirkt wie eine Schikane, ist aber ein Schutzwall des Browsers. Ohne ihn könnte
jede beliebige Webseite im Hintergrund Daten von Diensten laden, bei denen du gerade
angemeldet bist, und sie abgreifen. Deshalb erlaubt der Browser einer Seite nur dann,
Daten von einer fremden Herkunft zu lesen, wenn dieser Server das ausdrücklich
gestattet. Der entscheidende Punkt, der so oft übersehen wird: Es ist der Browser,
der blockiert, nicht der Server — die Anfrage kam meist an, aber der Browser
verweigert der Seite den Zugriff auf die Antwort. Genau darum klappt derselbe Aufruf
von der Kommandozeile, wo kein Browser dazwischensteht.
Daraus folgt, wo die Lösung liegt: beim Server, der die Daten liefert. Er muss im
Antwort-Header die eigene Herkunft als erlaubt ausweisen — gezielt, nicht pauschal
für alle, denn ein weit offener Zugriff kann selbst zur Lücke werden. Wer den fremden
Server nicht ändern kann, schaltet in der Entwicklung einen Proxy dazwischen, der die
Daten serverseitig holt, wo CORS gar nicht greift. Was man niemals tun sollte, ist,
den Schutz per Browser-Erweiterung abzuschalten — das kaschiert das Problem nur und
öffnet genau die Tür, die CORS bewacht.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Verstehen, wer hier blockiert
Der CORS-Fehler kommt vom Browser, nicht vom Server. Aus Sicherheitsgründen erlaubt der Browser einer Webseite nur dann, Daten von einer anderen Herkunft (anderer Domain, Port oder Protokoll) zu laden, wenn dieser Server es ausdrücklich gestattet. Fehlt die Erlaubnis, blockt der Browser die Antwort — die Anfrage selbst kam oft durchaus an.
2.
Die Erlaubnis am Server setzen
Die richtige Lösung liegt beim Server der API: Er muss im Antwort-Header die erlaubten Herkünfte angeben (Access-Control-Allow-Origin). Nur die tatsächlich benötigten Herkünfte eintragen, nicht pauschal alle — ein weit offener Zugriff kann eine Sicherheitslücke sein.
3.
Vorabanfragen beachten
Bei bestimmten Anfragen schickt der Browser zuerst eine Vorabanfrage (Preflight per OPTIONS). Der Server muss auch darauf mit den passenden Erlaubnis-Headern antworten, sonst scheitert schon dieser erste Schritt und die eigentliche Anfrage läuft nie.
4.
In der Entwicklung einen Proxy nutzen
Hat man keinen Zugriff auf den fremden Server, hilft während der Entwicklung ein lokaler Proxy: Die eigene Anwendung spricht mit dem Proxy auf derselben Herkunft, und dieser holt die Daten serverseitig — wo CORS keine Rolle spielt, weil die Regel nur den Browser betrifft.
5.
Keine unsicheren Abkürzungen nehmen
Browser-Erweiterungen, die CORS abschalten, oder das pauschale Öffnen für alle Herkünfte lösen das Problem nur scheinbar und reißen Sicherheitslücken auf. Sie gehören allenfalls in eine reine Testumgebung, niemals in den echten Betrieb.
Häufige Fragen (FAQ)
?Warum funktioniert die Anfrage mit curl, aber nicht im Browser?
Weil CORS eine Regel des Browsers ist, nicht des Servers. curl kennt keine Herkunftsprüfung und fragt einfach. Der Browser dagegen schützt den Benutzer davor, dass eine beliebige Webseite in seinem Namen fremde Dienste anspricht. Der Server antwortet in beiden Fällen – nur reicht der Browser die Antwort nicht durch.
?Kann ich CORS nicht einfach im Browser abschalten?
Man kann Chrome mit deaktivierter Sicherheitsprüfung starten, und genau das findet man in jedem Forum. Es ist eine schlechte Idee: Damit surft man mit abgeschaltetem Schutz durch das gesamte Netz, nur um ein lokales Problem zu umgehen. Der richtige Ort für die Erlaubnis ist der Server, in der Entwicklung ein Proxy.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Die neue Version ist online, der Browser zeigt die alte. Cache und Service Worker liefern hartnäckig weiter, was sie gespeichert haben.
SWLästigMixed Content: The page at … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.