CORS-Tester

Nächste

CORS-Fehler sind das “klassische” rot in der Browser-Konsole: Sie greifen auf eine API von einem anderen Ursprung zu und der Browser blockiert die Antwort. Dieser Tester sendet eine Preflight-OPTIONS-Anfrage an jede URL, die Sie einfügen, mit dem von Ihnen gewählten Ursprung und der gewählten Methode, und dekodiert die Access-Control-* Header, damit Sie genau sehen können, was der Server erlaubt, was er blockiert und warum der Browser sich beschwert.

So testen Sie CORS

  1. 1

    Geben Sie die Ziel-URL ein

    Der API-Endpunkt, den Sie von Ihrem Frontend aus aufrufen möchten. Fügen Sie die Abfragezeichenfolge und das Protokoll hinzu.

  2. 2

    Setzen Sie die Methode und den Ursprung

    GET/POST/PUT/DELETE/PATCH. Der Ursprung kann Ihre Seiten-URL oder ein beliebiger Ursprung sein, den Sie simulieren möchten.

  3. 3

    Das Preflight verstehen

    Der Tester sendet immer eine OPTIONS-Anfrage mit dem von Ihnen gewählten Ursprung und der Methode sowie dem Header Access-Control-Request-Headers: Content-Type, genau das Preflight, das ein Browser vor einer JSON-Anfrage sendet.

  4. 4

    Führen Sie den Test aus

    Der Tester sendet das Preflight und berichtet den HTTP-Status sowie die CORS-Antwortheader: Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials und Max-Age.

  5. 5

    Beheben Sie die Fehlkonfiguration

    Der Bericht kennzeichnet, was fehlt oder falsch ist, fehlendes Allow-Origin, verbotener Header, Methode nicht erlaubt.

Die wichtigen Header

Kopfzeile Funktion
Access-Control-Allow-Origin Welche Ursprünge die Antwort lesen dürfen
Access-Control-Allow-Methods Preflight: welche Methoden erlaubt sind
Access-Control-Allow-Headers Preflight: welche Anfrageheader erlaubt sind
Access-Control-Allow-Credentials Ob Cookies/Auth erlaubt sind
Access-Control-Expose-Headers Welche Antwortheader JS lesen kann
Access-Control-Max-Age Wie lange das Preflight-Ergebnis zwischengespeichert wird

Einfache vs. Preflight-Anfragen

Eine Anfrage ist “einfach” (kein Preflight), wenn alle dieser Punkte zutreffen:

  • Methode ist GET, HEAD oder POST.
  • Header sind auf Accept, Accept-Language, Content-Language, Content-Type (mit spezifischen Werten) beschränkt.
  • Content-Type, falls vorhanden, ist application/x-www-form-urlencoded, multipart/form-data oder text/plain.

Alles andere, ein JSON-Body, ein Authorization-Header, ein benutzerdefinierter X-Foo-Header, ein PUT/DELETE/PATCH, löst ein Preflight OPTIONS aus. Server müssen auf das Preflight mit den richtigen Allow-* Headern antworten, sonst wird die tatsächliche Anfrage nie gesendet.

Häufige CORS-Fehler

  • “Kein Access-Control-Allow-Origin-Header” → Server setzt den Header nicht. Beheben Sie dies auf dem Server, nicht im Client.
  • “Credentials-Modus erfordert, dass Allow-Origin nicht * ist” → wenn Sie Cookies senden, muss Allow-Origin ein spezifischer Ursprung sein (oder den Origin-Header echoen).
  • “Anfrageheader X nicht erlaubt” → fügen Sie X zu Access-Control-Allow-Headers in der Preflight-Antwort hinzu.
  • “Methode nicht erlaubt” → fügen Sie die Methode zu Access-Control-Allow-Methods hinzu.
  • “Umleitung in Preflight nicht erlaubt” → Preflight kann Umleitungen nicht folgen. Der OPTIONS-Endpunkt muss direkt antworten.

Allow-Origin: * vs. Echoing Origin

Access-Control-Allow-Origin: * ist permissiv, kann aber nicht mit Anmeldeinformationen kombiniert werden. In der Produktion echoen Sie den Anfrage-Origin zurück (nach Validierung gegen eine Erlaubenliste) und setzen Allow-Credentials: true, wenn Sie Cookies benötigen.

Proxying als Workaround

Wenn Sie den Server nicht kontrollieren können, entfernt ein dünner Proxy auf Ihrer eigenen Domain CORS vollständig, der Browser sieht den gleichen Ursprung. Viele Hosting-Plattformen (Vercel, Netlify, Cloudflare) bieten Rewrite-Regeln genau dafür an.

Häufig gestellte Fragen

Um zu verhindern, dass eine bösartige Seite private Daten auf einer anderen Seite mithilfe der Cookies Ihres Browsers liest. Ohne CORS könnte der Besuch von evil.com es ermöglichen, die interne API Ihrer Bank als Sie anzufordern. CORS zwingt die Bank, ausdrücklich Cross-Origin-Lesevorgänge zu erlauben.

Nur in der Entwicklung. Chromium hat ein --disable-web-security-Flag, aber es betrifft alle Seiten und ist gefährlich. Die richtige Lösung sind serverseitige Header oder ein Proxy.

Postman ist kein Browser, es ignoriert CORS vollständig. CORS wird nur von Browsern für JavaScript-Anfragen durchgesetzt. Ein Server, der in Postman funktioniert, ist nicht automatisch CORS-korrekt.

Bilder und klassische <script>-Tags laden Cross-Origin ohne CORS, aber JS kann deren Inhalte nicht lesen. <img crossorigin> und fetch() setzen CORS durch, weshalb canvas-gezeichnete Bilder ohne es “verunreinigt” werden.

Verwandte Tools