CORS-Header-Erklaerer

CORS-Header verstehen und Konfigurationen ueberpruefen

CORS Headers

Paste CORS headers

Enter response headers from your server to analyze security and configuration.

Analysis

Enter CORS headers to analyze configuration

Common CORS Headers

Access-Control-Allow-Origin - Which origins can access

Access-Control-Allow-Methods - Allowed HTTP methods

Access-Control-Allow-Headers - Allowed request headers

Access-Control-Allow-Credentials - Allow cookies/auth

Der CORS Header Explainer bietet eine interaktive Referenz und einen Konfigurationsvalidator für Cross-Origin Resource Sharing-Header und hilft Ihnen, CORS-Fehler zu verstehen, zu debuggen und zu beheben -- ohne Trial-and-Error-Deployment-Zyklen. Geben Sie Ihren Request-Origin, die Methode und benutzerdefinierte Header zusammen mit den CORS-Response-Headern des Servers ein und sehen Sie sofort, ob der Browser die Anfrage zulassen oder blockieren würde -- mit einer klaren Erklärung warum.

CORS verstehen

Wenn Sie jemals die Meldung "Access to XMLHttpRequest has been blocked by CORS policy" in Ihrer Browserkonsole gesehen haben, sind Sie auf einen der häufigsten und verwirrendsten Sicherheitsmechanismen des Webs gestoßen. CORS steht für Cross-Origin Resource Sharing und existiert, um Benutzer vor bösartigen Websites zu schützen, die versuchen, Anfragen im Namen des Benutzers an andere Websites zu senden. Ohne CORS könnte jede Webseite, die Sie besuchen, still Anfragen an die API Ihrer Bank senden und dabei Ihre eingeloggte Session nutzen -- CORS verhindert dies, indem es erfordert, dass der Server der Bank ausdrücklich dem Empfang von Anfragen von anderen Origins zustimmt.

Ein Origin wird durch die Kombination aus Schema, Host und Port definiert: https://app.example.com und https://api.example.com sind unterschiedliche Origins, obwohl sie dieselbe Root-Domain teilen. Wenn Ihr Frontend-JavaScript unter https://app.example.com eine Fetch-Anfrage an https://api.example.com/data sendet, prüft der Browser, ob der API-Server die richtigen CORS-Header gesendet hat, die besagen, dass er Anfragen von https://app.example.com erlaubt. Wenn die Header fehlen oder falsch sind, blockiert der Browser die Antwort für Ihr JavaScript, obwohl der Server die Anfrage tatsächlich verarbeitet und Daten zurückgesendet hat.

Die Verwirrung um CORS kommt von seinem geschichteten Design. Einfache Anfragen -- grundlegende GET oder POST mit Standard-Headern -- werden direkt durchgelassen, und der Browser prüft die CORS-Header in der Antwort. Aber jede Anfrage, die benutzerdefinierte Header, nicht standardmäßige Content-Types oder Methoden wie PUT oder DELETE verwendet, löst eine Preflight-Prüfung aus: Der Browser sendet zuerst eine OPTIONS-Anfrage, um den Server zu fragen, ob er die eigentliche Anfrage akzeptieren wird. Der Server muss auf diesen Preflight mit den korrekten Access-Control-Allow-*-Headern antworten, bevor der Browser die tatsächliche Anfrage sendet. Dieses Tool simuliert beide Szenarien, damit Sie Ihre Konfiguration vor dem Deployment validieren können.

So prüfen Sie eine CORS-Konfiguration

Geben Sie den Request-Origin (z. B. https://app.example.com), die HTTP-Methode und eventuelle benutzerdefinierte Header ein, die Ihr Frontend sendet.
Geben Sie die CORS-Response-Header des Servers ein (Access-Control-Allow-Origin, Access-Control-Allow-Methods usw.).
Klicken Sie auf Prüfen, um die Browser-CORS-Validierung zu simulieren.
Überprüfen Sie das Ergebnis: Das Tool erklärt, ob die Anfrage zugelassen oder blockiert würde und identifiziert den genauen Grund für ein eventuelles Scheitern.

CORS-Header-Beispiele

Einfache Anfrage (Zugelassen)

Anfrage-Detail	Wert
Origin	`https://app.example.com`
Methode	`GET`
Benutzerdefinierte Header	Keine

Response-Header	Wert
`Access-Control-Allow-Origin`	`https://app.example.com`

Ergebnis: Zugelassen. Der Origin stimmt exakt überein.

Preflight-Anfrage mit benutzerdefinierten Headern (Zugelassen)

Anfrage-Detail	Wert
Origin	`https://app.example.com`
Methode	`POST`
Benutzerdefinierte Header	`Content-Type: application/json`, `Authorization: Bearer token`

Response-Header	Wert
`Access-Control-Allow-Origin`	`https://app.example.com`
`Access-Control-Allow-Methods`	`GET, POST, PUT, DELETE`
`Access-Control-Allow-Headers`	`Content-Type, Authorization`
`Access-Control-Max-Age`	`86400`

Ergebnis: Zugelassen. Origin, Methode und Header stimmen alle überein. Der Preflight wird 24 Stunden gecacht.

Anfrage mit Credentials (Blockiert)

Anfrage-Detail	Wert
Origin	`https://app.example.com`
Methode	`GET`
Credentials	`include`

Response-Header	Wert
`Access-Control-Allow-Origin`	`*`
`Access-Control-Allow-Credentials`	`true`

Ergebnis: Blockiert. Wenn Access-Control-Allow-Credentials true ist, darf der Access-Control-Allow-Origin-Header nicht der Platzhalter * sein -- er muss den exakten Origin angeben.

Wann den CORS Header Explainer verwenden

Debugging von "CORS error" in Browserkonsolen -- Fügen Sie Ihre Anfrage-Details und Server-Header ein, um herauszufinden, warum der Browser die Anfrage genau blockiert.
API-CORS-Konfiguration einrichten -- Validieren Sie Ihre Access-Control-*-Header vor dem Deployment in die Produktion.
CDN- oder Reverse-Proxy-Header konfigurieren -- Testen Sie CORS-Header-Durchreichung bei Verwendung von CloudFront, Cloudflare oder nginx als Proxy.
Preflight vs. einfache Anfragen verstehen -- Erfahren Sie, welche Anfrage-Eigenschaften eine Preflight-OPTIONS-Anfrage auslösen.
Probleme mit Credentials und Cookies beheben -- Diagnostizieren Sie, warum Cookies oder Authorization-Header bei Cross-Origin-Anfragen nicht gesendet werden.
Schulung und Dokumentation -- Verwenden Sie den interaktiven Checker als Lehrmittel für Entwickler, die CORS zum ersten Mal lernen.

Wie CORS funktioniert

Einfache Anfragen vs. Preflight-Anfragen

Browser klassifizieren Cross-Origin-Anfragen in zwei Kategorien:

Einfache Anfragen werden direkt ohne Preflight-Prüfung gesendet. Eine Anfrage ist "einfach", wenn sie GET, HEAD oder POST mit nur Standard-Headern verwendet (Accept, Accept-Language, Content-Language, Content-Type beschränkt auf application/x-www-form-urlencoded, multipart/form-data oder text/plain).

Preflight-Anfragen werden für alles ausgelöst, was außerhalb der Kriterien für einfache Anfragen liegt. Der Browser sendet zuerst eine OPTIONS-Anfrage, und der Server muss mit entsprechenden Access-Control-Allow-*-Headern antworten, bevor die eigentliche Anfrage gesendet wird.

CORS-Header-Referenz

Header	Richtung	Zweck
`Access-Control-Allow-Origin`	Antwort	Gibt an, welche(r) Origin(s) auf die Ressource zugreifen können. Muss ein spezifischer Origin oder `*` sein.
`Access-Control-Allow-Methods`	Antwort (Preflight)	Listet die HTTP-Methoden auf, die der Server für die Ressource erlaubt.
`Access-Control-Allow-Headers`	Antwort (Preflight)	Listet die benutzerdefinierten Header auf, die der Server in der Anfrage erlaubt.
`Access-Control-Expose-Headers`	Antwort	Listet die Response-Header auf, die JavaScript lesen darf.
`Access-Control-Max-Age`	Antwort (Preflight)	Wie viele Sekunden der Browser die Preflight-Antwort cachen kann.
`Access-Control-Allow-Credentials`	Antwort	Ob Cookies und Credentials erlaubt sind. Kann nicht mit `Origin: *` verwendet werden.

Häufige CORS-Fehler

Access-Control-Allow-Origin: * zusammen mit Access-Control-Allow-Credentials: true setzen -- diese Kombination ist von der Spezifikation ausdrücklich verboten.
Content-Type in Access-Control-Allow-Headers vergessen, wenn JSON gesendet wird -- application/json ist kein "einfacher" Content-Type.
Die OPTIONS-Preflight-Methode nicht auf dem Server behandeln, was zu einer 405 Method Not Allowed-Antwort führt.
Access-Control-Expose-Headers weglassen und sich wundern, warum JavaScript benutzerdefinierte Response-Header nicht lesen kann.

CORS-Validierungsablauf

Browser                                    Server
  |                                          |
  |-- Ist dies eine einfache Anfrage? ----->|
  |   (GET/HEAD/POST, Standard-Header)      |
  |                                          |
  |   JA: Anfrage direkt senden              |
  |   NEIN: Zuerst OPTIONS-Preflight senden  |
  |                                          |
  |<--- Preflight-Antwort ------------------|
  |   Access-Control-Allow-Origin: ...       |
  |   Access-Control-Allow-Methods: ...      |
  |   Access-Control-Allow-Headers: ...      |
  |                                          |
  |-- Prüfen: Stimmt der Origin überein? -->|
  |-- Prüfen: Ist die Methode erlaubt? ---->|
  |-- Prüfen: Sind die Header erlaubt? ---->|
  |                                          |
  |   ALLE BESTANDEN: Eigentliche Anfrage    |
  |   EINER FEHLSCHLAG: Blockieren und       |
  |                     CORS-Fehler loggen   |

Praktische Tipps zur CORS-Konfiguration

Der sicherste Ansatz für die CORS-Konfiguration ist, mit den restriktivsten Einstellungen zu beginnen und nur das zu öffnen, was Ihre Anwendung benötigt. Beginnen Sie damit, die exakten Origins anzugeben, die Zugriff haben sollen, anstatt * zu verwenden. Wenn Ihr Frontend unter https://app.example.com läuft, setzen Sie Access-Control-Allow-Origin: https://app.example.com explizit. Dies verhindert, dass andere Websites Cross-Origin-Anfragen an Ihre API stellen. Wenn Sie mehrere Origins unterstützen müssen, implementieren Sie eine dynamische Origin-Prüfung auf dem Server -- lesen Sie den Origin-Request-Header, prüfen Sie ihn gegen Ihre Allowlist und geben Sie ihn in der Antwort zurück.

Preflight-Caching ist eine oft übersehene Optimierung. Ohne Access-Control-Max-Age sendet der Browser vor jeder einzelnen Cross-Origin-Anfrage eine OPTIONS-Preflight-Anfrage. Bei einer Anwendung mit häufigen API-Aufrufen verdoppelt dies die Anzahl der Anfragen. Access-Control-Max-Age: 3600 (1 Stunde) sagt dem Browser, das Preflight-Ergebnis zu cachen und eliminiert redundante OPTIONS-Anfragen. Beachten Sie, dass die meisten Browser dies auf etwa 7.200 Sekunden (2 Stunden) begrenzen, und Chrome es auf 2 Stunden begrenzt, selbst wenn Sie einen höheren Wert setzen.

Wenn Ihre API benutzerdefinierte Response-Header zurückgeben muss, die JavaScript lesen soll (wie Paginierungsinformationen in X-Total-Count oder Request-IDs in X-Request-ID), müssen Sie diese in Access-Control-Expose-Headers auflisten. Standardmäßig kann JavaScript nur eine kleine Menge "CORS-sicherer" Response-Header lesen: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified und Pragma. Jeder benutzerdefinierte Header ist für Ihren Frontend-Code unsichtbar, es sei denn, Sie legen ihn explizit offen. Dies ist eine häufige Quelle der Verwirrung beim Debugging von Paginierungs- oder Rate-Limit-Anzeigeproblemen.

Häufig gestellte Fragen

Warum funktioniert meine Anfrage in Postman, scheitert aber im Browser?

Postman und andere API-Clients erzwingen kein CORS, weil CORS ein reiner Browser-Sicherheitsmechanismus ist. Die Same-Origin-Policy wird vom Browser durchgesetzt, um Benutzer vor bösartigen Skripten zu schützen. Server-zu-Server-Anfragen sind von CORS nicht betroffen.

Kann ich Access-Control-Allow-Origin: * mit Cookies verwenden?

Nein. Wenn die Anfrage Credentials enthält (Cookies, HTTP-Authentifizierung), muss der Server mit dem exakten anfragenden Origin antworten, nicht mit *. Setzen Sie Access-Control-Allow-Origin: https://app.example.com und Access-Control-Allow-Credentials: true zusammen.

Was ist Access-Control-Max-Age und sollte ich es setzen?

Es teilt dem Browser mit, wie lange er die Preflight-Antwort cachen soll. Ohne dies sendet der Browser vor jeder Cross-Origin-Anfrage eine OPTIONS-Anfrage. Ein Wert von 86400 (24 Stunden) reduziert den Preflight-Overhead erheblich. Die meisten Browser begrenzen dies auf 7200 Sekunden (2 Stunden), unabhängig vom gesetzten Wert.

Warum erhalte ich einen CORS-Fehler, obwohl der Server 200 zurückgibt?

CORS wird vom Browser durchgesetzt, nicht vom Server. Der Server verarbeitet die Anfrage und sendet eine 200-Antwort, aber wenn die Antwort den korrekten Access-Control-Allow-Origin-Header nicht enthält, blockiert der Browser den Zugriff von JavaScript auf die Antwortdaten. Die Anfrage ist auf der Serverseite erfolgreich -- Sie können das Ergebnis nur nicht von Ihrem Frontend lesen.

Wie gehe ich mit CORS bei WebSocket-Verbindungen um?

WebSocket-Verbindungen verwenden kein CORS. Der initiale HTTP-Handshake, der zu WebSocket upgradet, unterliegt keinem CORS-Preflight. Sie sollten jedoch den Origin-Header auf der Serverseite während des WebSocket-Handshakes validieren, um Cross-Origin-WebSocket-Hijacking zu verhindern.

Kann ich CORS verwenden, um einzuschränken, welche Server meine API aufrufen können?

Nein. CORS beschränkt nur browserbasierte Anfragen. Jeder Server, jedes Skript oder jedes Kommandozeilen-Tool kann Ihre API direkt ohne CORS-Einschränkungen aufrufen. Für Server-zu-Server-Authentifizierung verwenden Sie API-Keys, OAuth-Tokens oder mutual TLS. CORS ist speziell ein Browser-Sicherheitsfeature, kein allgemeiner Zugriffskontrollmechanismus.