01
Origin der aufrufenden App verwenden
Tragen Sie Schema, Host und Port der Frontendseite ein, nicht die API-Adresse. Die lokale Analyse simuliert diesen Ursprung; Browser-GET nutzt fest die Origin von HeyUtils.
HTTP / Anfragen debuggen
CORS Checkerwenn der Browser die Antwort lesen soll
Echte Antwortheader und bei Bedarf OPTIONS-Header einfügen. Ein Netztest startet nur auf Klick.
CORS Checker
Header der echten Antwort
OPTIONS-Antwortheader (optional)
Eingefügte Header bleiben im Browser; die lokale Analyse sendet keine Anfrage.
Ergebnis
Bitte Antwortheader einfügen.
Anfragebedingungen
Diese Origin gilt nur für die lokale Analyse. Browser-GET verwendet die echte Origin dieser Seite.
Bitte Antwortheader einfügen.
Der Server meldet HTTP 200, doch fetch scheitert? Ein CORS Checker trennt eine eingegangene Antwort von der Erlaubnis des Browsers, sie an JavaScript weiterzugeben.
Für CORS prüfen Sie zuerst eingefügte Header mit der Origin Ihrer App. Wählen Sie Methode und Headernamen; bei nötigem Preflight ergänzen Sie die OPTIONS-Antwort. Ohne Klick auf Browser-GET erfolgt keine Netzverbindung.
Warum dieser CORS Checker hilft
Servererfolg und Leserecht sind zwei verschiedene Fragen.
HTTP 200 kann trotzdem verborgen bleiben
Ein einfaches GET erreicht den Server, aber ohne passende Allow-Origin-Angabe bleibt seine Antwort für JavaScript gesperrt. Der CORS Checker bewertet deshalb nicht nur den HTTP-Status.
OPTIONS nicht mit der Endantwort verwechseln
JSON POST oder Authorization können zuerst eine Preflight-Anfrage auslösen. Fehlt die OPTIONS-Antwort, bleibt dieser Schritt ungeprüft. Fügen Sie Status und Header ein, um die verweigerte Methode oder den Headernamen zu sehen.
Beide Freigaben nachvollziehen
02
Preflight-Bedingungen prüfen
application/json, Authorization und andere Methoden können OPTIONS auslösen. Der Name eines Anfrage-Headers genügt; sein Wert ist für diese Einstufung nicht nötig. Ohne OPTIONS-Antwort bleibt die Freigabe offen.
03
Nur aktuelle Berichte exportieren
Jede Eingabeänderung sperrt Kopieren und Download des alten Ergebnisses. Die Automatik wartet 350 ms. Nach dem Ausschalten starten Sie per Schaltfläche oder Strg/Cmd + Enter.
Welche CORS-Regel gerade greift
Origin und Zugangsdaten abgleichen
Bei credentials: include verbietet der Browser Allow-Origin: *. Eine konkrete Origin benötigt zudem Allow-Credentials: true. Ein Authorization-Header und der Credentials-Modus sind unterschiedliche Bedingungen.
Methode und Header einzeln erklären
Die Preflight-Anfrage prüfen heißt OPTIONS-Status, Allow-Methods und Allow-Headers getrennt mit den angefragten Werten vergleichen. Fehlende Namen erscheinen ausdrücklich im Bericht.
Sichtbare Header und Cachehinweise
Expose-Headers und Vary: Origin werden angezeigt. Eine einzelne Antwort reicht nicht, um das Spiegeln beliebiger Ursprünge nachzuweisen.
Echtes GET nur auf Wunsch
Ein Klick startet ein GET ohne Zugangsdaten von der aktuellen Seite. Auch ein HTTP-Fehler kann lesbar sein. Bei abgewiesenem fetch bleiben Status und Antwortheader verborgen.
Was die Prüfung nicht belegt
- Eingefügte Header sind kein Live-Test
- Die lokale CORS Konfiguration testen bedeutet eine Simulation anhand Ihres Textes. Ohne OPTIONS-Antwort lässt sich ein benötigter Preflight nicht bestätigen, selbst wenn die Endantwort richtig aussieht.
- Origin lässt sich im Browser nicht fälschen
- Der CORS Checker sendet im Browser nur GET von der echten Seiten-Origin, ohne Cookies oder eigene Headerwerte. Ein Erfolg beim gleichen Ursprung bestätigt keine Cross-Origin-Freigabe.
- Kein Proxy und kein Sicherheits-Scan
- Es werden weder beliebige URLs serverseitig abgerufen noch Methoden mit Schreibwirkung versendet. Ein fehlendes Allow-Origin ist bei nur gleichursprünglich genutzten Ressourcen nicht automatisch ein Fehler.
- Unsichtbar heißt nicht fehlend
- Browser-Skripte sehen nur standardmäßig erlaubte oder explizit exponierte Antwortheader. Vollständige Drahtdaten gehören in DevTools oder Serverprotokolle.
Fragen zum CORS Checker
Warum schlägt eine Anfrage mit einem CORS-Fehler fehl, obwohl der Server erfolgreich geantwortet hat?
Der Server kann erfolgreich antworten, während der Browser die Antwort für JavaScript verbirgt. Prüfen Sie Allow-Origin der echten Antwort und bei komplexen Anfragen zusätzlich die separate OPTIONS-Antwort.
Was ist der Unterschied zwischen einer einfachen und einer Preflight-Anfrage?
Einfache GET-Anfragen gehen direkt zum Server. JSON POST oder eigene Header erfordern zuerst eine OPTIONS-Freigabe für Origin, Methode und Headernamen; danach braucht auch die Endantwort eine passende Origin.
Sendet die Prüfung von CORS-Headern hier meine Daten an einen Server?
Im lokalen Modus werden eingefügte Header nicht gesendet. Nur wenn Sie Browser-GET wählen und starten, sendet Ihr Browser die URL als GET ohne Zugangsdaten.
Schützt CORS eine API vor bösartigen Anfragen?
Nein. CORS begrenzt das Lesen durch Browser-JavaScript. Authentifizierung, Autorisierung und serverseitige Prüfung bleiben notwendig; curl erzwingt diese Browserregel nicht.
Warum funktioniert Access-Control-Allow-Origin: * nicht zusammen mit credentials: include?
Bei credentials: include verlangt der Browser eine exakt passende Origin sowie Allow-Credentials: true. Ein Stern in Allow-Origin kann diese Antwort nicht für Skripte freigeben.
Ein anderer Fall fehlt?
CORS Checker mit echten Headern nutzen
Kopieren Sie die echte Antwort und bei Bedarf OPTIONS aus DevTools. Der CORS Checker zeigt, ob die Preflight- und die Leseregel zusammenpassen, bevor Sie die Serverkonfiguration ändern.
Standardmäßig lokal; GET nur nach einem Klick.