Netzwerk/HTTP
CORS Checker / Explainer
Schritt für Schritt erklären, ob der Browser eine Cross-Origin-Anfrage erlaubt — Simple/Preflight-Klassifizierung, Prüfung der Access-Control-*-Header der Antwort, Zusammenfassung.
Einer pro Zeile, „Name" oder „Name: Wert" — der Wert beeinflusst die Klassifizierung nicht.
Entnehmen Sie sie dem Network-Tab der DevTools (Header der Antwort selbst oder des Preflight-OPTIONS) oder mit curl -I.
CORS (Cross-Origin Resource Sharing) ist ein Browser-Mechanismus, der entscheidet, ob JavaScript von einer Website eine Antwort von einem Server auf einer anderen Domain lesen darf. Dieses Tool geht Schritt für Schritt durch, ob eine bestimmte Anfrage erfolgreich sein wird und welche Access-Control-*-Header dafür nötig sind.
So verwendest du es
- Gib Methode, Origin der Anfrage und die Antwort-Header des Servers (Access-Control-Allow-Origin usw.) an — das Tool bestimmt, ob der Browser die Anfrage durchlässt.
- Die Einstufung „simple" vs. „preflight" zeigt, ob der Browser zuerst eine OPTIONS-Preflight-Anfrage sendet.
- Die Zusammenfassung nennt den genauen Grund für ein Scheitern, wenn eine Anfrage blockiert würde — schneller, als die Fehlermeldung der Browserkonsole zu entziffern.
Typische Anwendungsfälle
- Den klassischen Fehler „has been blocked by CORS policy" Schritt für Schritt debuggen, statt zu raten, was fehlt.
- Die CORS-Konfiguration eines Backends prüfen, bevor Frontend und API in Produktion auf getrennten Domains liegen.
- Verstehen, warum eine Anfrage mit credentials: include abgelehnt wird, obwohl Access-Control-Allow-Origin korrekt aussieht.
Was du wissen solltest
CORS schützt den Browser des Nutzers, nicht den Server — die Einschränkung gilt nur für Anfragen aus Seiten-JavaScript im Browser, nicht für Anfragen von curl, Postman oder Server-zu-Server.
Access-Control-Allow-Origin: * ist nicht mit credentials: include kompatibel — bei Anfragen mit Cookies oder Autorisierung muss der Server einen konkreten Origin statt eines Platzhalters zurückgeben.
Häufig gestellte Fragen
Warum schlägt eine Anfrage mit einem CORS-Fehler fehl, obwohl der Server erfolgreich geantwortet hat?
CORS wird vom Browser durchgesetzt, nicht vom Server — fehlt der Antwort ein Access-Control-Allow-Origin-Header, der zur anfragenden Origin passt, blockiert der Browser JavaScript daran, die Antwort zu lesen, obwohl die Anfrage selbst abgeschlossen wurde.
Was ist der Unterschied zwischen einer einfachen und einer Preflight-Anfrage?
Einfache Anfragen (grundlegendes GET/POST mit Standard-Headern) gehen direkt durch, während Anfragen mit benutzerdefinierten Headern, anderen Methoden oder bestimmten Content-Typen zunächst eine Preflight-OPTIONS-Anfrage auslösen, um die Erlaubnis zu prüfen, bevor die eigentliche Anfrage gesendet wird.
Sendet die Prüfung von CORS-Headern hier meine Daten an einen Server?
Das Tool untersucht Header, die Sie bereitstellen, oder ruft sie direkt aus Ihrem Browser ab — kein zwischengeschalteter Server speichert Ihre Anfragedaten.
Schützt CORS eine API vor bösartigen Anfragen?
Nein. CORS schränkt nur ein, was JavaScript im Browser lesen darf — ein Angreifer mit curl, Postman oder einem Backend-Skript umgeht es vollständig, daher müssen echte Authentifizierung und Autorisierung auf dem Server erfolgen.
Warum funktioniert Access-Control-Allow-Origin: * nicht zusammen mit credentials: include?
Die Spezifikation verbietet diese Kombination absichtlich aus Sicherheitsgründen: Credentials (Cookies, Autorisierungs-Header) zusammen mit einem Wildcard zu erlauben, der jeden Origin akzeptiert, wäre eine schwerwiegende Sicherheitslücke, daher muss der Server bei Verwendung von Credentials einen exakten Origin zurückgeben.