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.
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: *).
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.
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.
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.
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.
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.
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 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.
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.
Access-Control-Allow-Origin*Permite cualquier origen (no funciona con credenciales)Access-Control-Allow-MethodsGET, POSTMétodos permitidos: GET, POSTAccess-Control-Allow-Origin: https://myapp.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization