CORS-Tester

Postman und curl sind keine Browser, sie ignorieren die Same-Origin-Policy komplett — sie senden die Anfrage und lesen die Antwort, egal welche Header zurückkommen. Ein Browser ist strenger: Ruft JavaScript von einem Origin ein anderes Schema, eine andere Domain oder einen anderen Port auf, darf Ihr Code die Antwort nur lesen, wenn der Server den richtigen Access-Control-Allow-Origin-Header zurückgibt. Fehlt dieser Header, erreicht die Anfrage den Server trotzdem und liefert Daten zurück, aber der Browser versteckt die Antwort vor Ihrem Skript und protokolliert den CORS-Fehler. Deshalb kann ein Endpunkt in Postman gesund aussehen, in der Konsole aber fehlschlagen. Dieses Tool untersucht die tatsächlich vom Server gesendeten CORS-Header, sodass Sie bestätigen können, ob das Problem an der Serverkonfiguration liegt und nicht an Ihrem Fetch-Code. Fügen Sie Ihren Endpunkt ein, um genau zu sehen, welche Header vorhanden sind.

Ein Preflight ist eine automatische OPTIONS-Anfrage, die der Browser vor der eigentlichen Anfrage sendet, um zu prüfen, ob der tatsächliche Aufruf erlaubt ist. Das passiert bei „nicht einfachen“ Anfragen: Methoden wie PUT, DELETE oder PATCH, eigene Request-Header oder Content-Types wie application/json. Der Browser sendet dabei Access-Control-Request-Method und Access-Control-Request-Headers, und der Server muss mit passenden Access-Control-Allow-Methods- und Access-Control-Allow-Headers-Werten antworten, sonst wird die eigentliche Anfrage nie ausgelöst. Einfache GET- und POST-Anfragen mit Standard-Headern überspringen diesen Schritt. Da Preflights in den meisten Fetch-Codes unsichtbar bleiben, ist ein fehlgeschlagener OPTIONS-Handshake eine häufige und verwirrende Ursache für CORS-Fehler. Mit diesem Tester können Sie die Anfrage als OPTIONS senden und die vom Server gemeldeten erlaubten Methoden und Header einsehen, statt aus einer blockierten Konsolenmeldung zu raten.

Die CORS-Spezifikation verbietet die Kombination von Anfragen mit Zugangsdaten und einem Wildcard-Origin, und jeder Browser setzt das durch. Wenn Sie Cookies oder Authorization-Header cross-origin senden, muss der Server einen konkreten Origin in Access-Control-Allow-Origin zurückspiegeln — niemals das Sternchen als Sammelbegriff. Antwortet ein Server sowohl mit Access-Control-Allow-Credentials: true als auch mit einem Wildcard bei Access-Control-Allow-Origin, lehnt der Browser die Antwort rundweg ab und Ihre Anfrage schlägt fehl, obwohl die Header freizügig wirken. Die Lösung ist, den exakt anfragenden Origin zu spiegeln statt ein Wildcard zu verwenden, und den Credentials-Header weiterhin auf true zu setzen. Dieses Tool markiert genau diese gefährliche Kombination als Fehler in seiner CORS-Analyse, damit Sie sie erkennen, bevor sie ein authentifiziertes Frontend lahmlegt. Testen Sie Ihren Endpunkt mit Zugangsdaten hier, um zu prüfen, ob der Origin konkret statt wildcard ist.

Ein Wildcard-Origin erlaubt jeder Website im Internet, Cross-Origin-Anfragen an Ihre API zu stellen und die Antwort zu lesen — für wirklich öffentliche Daten wie offene Datensätze, öffentliche Nur-Lese-APIs oder statisches JSON ist das völlig unbedenklich. Riskant wird es, sobald der Endpunkt irgendetwas Sensibles zurückgibt oder mit den Cookies eines Nutzers erreichbar ist, denn dann könnte eine bösartige Website ihn im Namen eines Besuchers aufrufen. Als Faustregel gilt: Beschränken Sie Access-Control-Allow-Origin auf die konkreten Domains, die legitim Zugriff benötigen, statt es für alle zu öffnen, und kombinieren Sie ein Wildcard nie mit Credentials. Dieser Tester markiert einen Wildcard-Origin als Warnung und eine konkrete Domain als gut, sodass Sie auf einen Blick sehen, wie exponiert ein Endpunkt ist. Testen Sie Ihre URL hier, um zu prüfen, ob die Origin-Richtlinie zur Sensibilität der ausgelieferten Daten passt.

Access-Control-Max-Age teilt dem Browser mit, wie viele Sekunden er das Ergebnis einer Preflight-OPTIONS-Anfrage zwischenspeichern darf. Solange dieser Cache gültig ist, überspringt der Browser den zusätzlichen Roundtrip und sendet die eigentliche Anfrage direkt, was Apps spürbar beschleunigt, die viele nicht einfache Anfragen an denselben Endpunkt senden. Ohne diesen Header preflighted der Browser womöglich bei jedem Aufruf erneut, was Latenz hinzufügt. Die Werte werden vom Browser gedeckelt — Chrome begrenzt den Cache auf wenige Stunden, unabhängig von einem höheren angegebenen Wert —, sodass ein extrem hoher Wert über diese Obergrenze hinaus keinen Nutzen bringt. Fehlt Max-Age, bedeutet das schlicht kein Preflight-Caching. Dieses Tool liest den Header aus und rechnet die Rohsekunden in seiner Analyse in Minuten um, damit Sie schnell einschätzen können, wie aggressiv Preflights zwischengespeichert werden. Testen Sie Ihren Endpunkt, um zu sehen, ob er ein sinnvolles Max-Age setzt.