Text & Dokumente
Zahlen & Berechnung
Daten & Formate
Sicherheit
Entwicklung & DevOps
Künstliche Intelligenz
Finanzen
Gesundheit & Wohlbefinden
Produktivität
Spiele & Unterhaltung
Multimedia & Design
Unternehmen
Bedienungsanleitung
Was es ist und wofür es dient

CORS (Cross-Origin Resource Sharing) ist der Mechanismus, mit dem ein Browser entscheidet, ob eine Website die Antwort einer API lesen darf, die auf einem anderen Origin liegt (andere Domain, Port oder Protokoll). Ohne die richtigen CORS-Header blockiert der Browser das Lesen aus Sicherheitsgründen. Dieses Tool simuliert diese Browser-Prüfung: Es erklärt dir, ohne eine echte Anfrage zu senden und alles in deinem Browser, ob dein Server den Aufruf zulassen würde und warum.

Was du eingeben musst

Fülle drei Dinge aus:

• Origin (Browser) — die URL der App, die die Anfrage stellt (z. B. https://myapp.com). Das ist der Wert, den der Browser im Origin-Header senden würde.
• HTTP-Methode — GET, POST, PUT, DELETE… Die Methode entscheidet, ob ein Preflight nötig ist.
• Antwort-Header des Servers — füge die Header ein, die deine API zurückgibt, einen pro Zeile, im Format Name: Wert (z. B. Access-Control-Allow-Origin: *). Die Analyse aktualisiert sich von selbst, während du tippst.

Einfache Anfrage vs. Preflight

Es gibt zwei Arten von Cross-Origin-Anfragen:

• Einfache Anfrage — mit GET, POST oder HEAD und einfachen Headern sendet der Browser sie direkt und prüft danach, ob die Antwort Access-Control-Allow-Origin enthält.
• Mit Preflight — bei Methoden wie PUT, PATCH oder DELETE (oder benutzerdefinierten Headern) sendet der Browser zuvor eine vorgelagerte Anfrage vom Typ OPTIONS, um um Erlaubnis zu bitten. Das Werkzeug markiert automatisch, wann deine Methode einen Preflight benötigt.

Der Preflight (OPTIONS) im Detail

Der Preflight ist eine OPTIONS-Anfrage, die der Browser vor der eigentlichen sendet, um zu fragen „lässt du mich das tun?“. In diesem Tool wird er bei den Methoden PUT, PATCH, DELETE und OPTIONS ausgelöst. Erscheint der Hinweis, muss dein Server auf dieses OPTIONS mit den passenden CORS-Headern antworten (erlaubter Origin, Methoden und Header); sonst bricht der Browser die eigentliche Anfrage ab, selbst wenn deine API funktioniert. Access-Control-Max-Age hinzuzufügen vermeidet, den Preflight bei jedem Aufruf zu wiederholen.

Access-Control-Allow-Origin

Ist der unverzichtbare Header: gibt an, welcher Origin die Antwort lesen darf.

• * — erlaubt jeden Origin, funktioniert aber nicht mit Credentials (Cookies).
• Ein konkreter Origin, z. B. https://myapp.com — nur dieser Origin, und er muss exakt mit deinem Origin übereinstimmen (Protokoll + Domain + Port).

Fehlt dieser Header, oder stimmt der Wert weder mit * noch mit deinem Origin überein, wird die Anfrage blockiert.

Access-Control-Allow-Methods

Listet die HTTP-Methoden, die der Server von einem anderen Origin akzeptiert, durch Kommas getrennt (z. B. GET, POST, PUT, DELETE). Ist vor allem beim Preflight relevant. Gibst du diesen Header an, enthält er aber nicht deine Methode, markiert das Werkzeug dies als Problem und blockiert die Anfrage. Lässt du ihn weg, wird die Methode nicht geprüft.

Access-Control-Allow-Headers

Zählt auf, welche Anfrage-Header der Client senden darf (z. B. Content-Type, Authorization). Der Browser verlangt ihn im Preflight, wenn deine Anfrage nicht standardmäßige Header sendet. Sendet deine App Authorization und taucht dies hier nicht auf, blockiert der Browser den Aufruf.

Access-Control-Allow-Credentials

Mit dem Wert true erlaubt er das Senden von Cookies und Credentials bei der Cross-Origin-Anfrage.

• Achtung, wichtige Falle: Credentials sind inkompatibel mit Access-Control-Allow-Origin: *. Verwendest du Credentials, muss der Origin spezifisch sein (z. B. https://myapp.com), niemals *. Beides zu kombinieren führt dazu, dass der Browser die Antwort ablehnt.

Access-Control-Max-Age und Vary

Access-Control-Max-Age gibt an, wie viele Sekunden der Browser die Antwort des Preflights cachen darf (z. B. 86400 = 24 Std.), um OPTIONS nicht bei jedem Aufruf zu wiederholen. Das Werkzeug fügt ihn den vorgeschlagenen Headern hinzu, wenn deine Methode einen Preflight benötigt. Denke außerdem daran, Vary: Origin auf deinem Server hinzuzufügen, wenn du einen konkreten Origin zurückgibst, damit Caches keine Antworten unterschiedlicher Origins vermischen.

So liest du das Ergebnis

Nach der Analyse siehst du:

• Ein Banner, grün (erlaubt) oder rot (blockiert), mit dem genauen Grund: Access-Control-Allow-Origin fehlt, der Origin stimmt nicht überein oder die Methode ist nicht erlaubt.
• Gefundene CORS-Header — jeder erkannte Header mit Wert und Erklärung.
• Erkannte Probleme — was die Anfrage verhindert.
• Funktioniert, ist aber ein Sicherheitsrisiko — was der Browser TATSÄCHLICH durchlässt und du nicht wollen solltest, etwa den Origin null mit Credentials zuzulassen.
• Dein Browser erlaubt es, aber verlass dich nicht darauf — was Chrome heute akzeptiert und die Spezifikation nicht garantiert.
• Vorgeschlagene Header — ein Block, fertig zum Kopieren in die Konfiguration deines Servers.

CORS ExplainerAnalysiere die CORS-Header deines Servers
CORS-ErklärungAnalysiere und erkläre die CORS-Header deines Servers
URL der App, die die Anfrage stellt

Markiere das, wenn dein Code <code>credentials: 'include'</code> (oder <code>withCredentials</code>) verwendet. Das ändert die Regeln: Der Origin darf nicht mehr <code>*</code> sein, Wildcards gelten nicht mehr, und der Server muss mit <code>Access-Control-Allow-Credentials: true</code> antworten.

Die der ANFRAGE, nicht die der Antwort. Sie entscheiden, ob der Browser zuerst ein OPTIONS sendet, und sie sind es, die „Access-Control-Allow-Headers" abdecken muss.

CORS permitido correctamente
Der Browser sendet zuerst eine OPTIONS-Anfrage (Preflight), wegen der Content-Type application/json. Dein Server muss auch auf DIESES OPTIONS antworten, nicht nur auf die eigentliche Anfrage.

Gefundene CORS-Header

Access-Control-Allow-Originhttps://myapp.comPermite solo el origen: https://myapp.com
Access-Control-Allow-MethodsPOSTMétodos permitidos: POST
Access-Control-Allow-HeadersContent-TypeCabeceras permitidas en la petición: Content-Type

Vorgeschlagene Header für deinen Server

Access-Control-Allow-Origin: https://myapp.com
Vary: Origin
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
Das wird anhand der Header entschieden, die du einfügst, ohne ins Netz zu gehen — deshalb funktioniert es auch für eine lokale oder private API. Wenn du die Anfrage WIRKLICH abschicken und sehen willst, ob dein Server geantwortet hat, gibt es die API-Werkbank.