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) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
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.