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) steuert, ob eine Website eine API mit einem anderen Origin aufrufen darf. Dieses Tool simuliert diese Browser-Prüfung und erklärt dir, ohne eine echte Anfrage zu senden, ob dein Server den Aufruf zulassen würde.

Was du eingeben musst

Fülle den Origin (die URL der App, die die Anfrage stellt), die HTTP-Methode (GET, POST, PUT…) aus und füge die Antwort-Header deines Servers ein, einen pro Zeile (zum Beispiel Access-Control-Allow-Origin: *).

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.

Preflight (OPTIONS)

Manche Methoden und Header zwingen den Browser, zuerst eine Preflight-Anfrage mit der Methode OPTIONS zu senden. Wenn das Tool das erkennt, muss dein Server auf dieses OPTIONS mit den passenden CORS-Headern antworten.

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

Das Banner zeigt an, ob die Anfrage erlaubt oder blockiert ist und warum. Darunter wird jeder erkannte CORS-Header erklärt, die gefundenen Probleme werden aufgelistet und ein Block vorgeschlagener Header wird bereitgestellt, fertig zum Kopieren auf deinen Server.

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

Márcalo si tu código usa credentials: 'include' (o withCredentials). Cambia las reglas: el origen ya no puede ser *, los comodines dejan de valer y el servidor tiene que responder Access-Control-Allow-Credentials: true.

Las de la PETICIÓN, no las de la respuesta. Son las que deciden si el navegador manda antes un OPTIONS, y las que «Access-Control-Allow-Headers» tiene que cubrir.

CORS permitido correctamente
El navegador mandará antes una petición OPTIONS (preflight), por el Content-Type application/json. Tu servidor tiene que contestar también a ESE OPTIONS, no solo a la petición real.

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
Esto se decide sobre las cabeceras que pegues, sin salir a la red — por eso vale también para una API local o privada. Si quieres lanzar la petición de VERDAD y ver si tu servidor llegó a contestar, está el Banco de trabajo de APIs.