VoriTools

CORS-Preflight-Header analysieren

Modellieren Sie die Anfrage über die Eingabefelder. Es wird keine Anfrage gesendet; Serververhalten und Wertbeschränkungen sind separat zu testen.

Läuft lokal in deinem Browser
Kategorie ansehen: API-Entwicklung (15)
Dieses Werkzeug verarbeitet alle Daten lokal in deinem Browser.
Browseranfrage und kopierte Response-HeaderDieser Prüfer modelliert nur Browserregeln; er kontaktiert keine API und verwendet keine Zugangsdaten erneut.

Eine CORS-Anfrage des Browsers gegen kopierte Response-Header modellieren

Dieser Prüfer modelliert eine CORS-Anfrage des Browsers gegen die Response-Header, die Sie einfügen. Er beantwortet eine Frage: Würde der Browser die Antwort lesen lassen und würde der Preflight, wo einer nötig ist, akzeptiert?

Alles läuft im Tab. Es wird keine Anfrage gesendet; die Zusammenfassung beschreibt also, was die kopierten Header erlauben, nicht was der echte Server heute zurückgibt.

  1. Tragen Sie die Request-Origin ein (Schema, Host, Port) und wählen Sie die Methode. PUT, PATCH und DELETE lösen einen Preflight aus, GET, HEAD und POST meist nicht.
  2. Listen Sie die Header, die der Browser in Access-Control-Request-Headers nennen würde, zum Beispiel Authorization, X-Request-ID, und aktivieren Sie Credentials, wenn die Anfrage Cookies oder HTTP-Auth sendet.
  3. Fügen Sie den kompletten Response-Header-Block als Zeilen `Name: Wert` ein und klicken Sie auf CORS-Richtlinie analysieren.
  4. Lesen Sie zuerst die Entscheidung, dann die Prüfungen: Jede Zeile nennt den Header, der die Anfrage erlaubt oder blockiert hat. Kopieren oder laden Sie die Zusammenfassung herunter.

Wie der Prüfer Access-Control-Header liest und wo er aufhört

Origin-Abgleich und Credentials

Access-Control-Allow-Origin muss die Request-Origin exakt wiederholen: Schema und Host in Kleinschreibung, Standard-Ports entfallen, kein abschließender Schrägstrich. Chrome lehnt `https://app.example.com/` für die Origin `https://app.example.com` ab, und der Prüfer meldet denselben Konflikt.

`*` erlaubt jede Origin nur, wenn die Anfrage keine Credentials sendet. Mit Cookies oder HTTP-Auth muss die Antwort die Origin wiederholen und `Access-Control-Allow-Credentials: true` ergänzen; die Platzhalter-Origin wird dann blockiert, obwohl sie großzügig aussieht.

Was einen Preflight braucht und was ohne ihn durchgeht

Ein JSON-Content-Type oder ein eigener Header lassen den Browser zuerst ein OPTIONS-Preflight senden. Chrome verlangt dann einen passenden Eintrag in Access-Control-Allow-Methods und in Access-Control-Allow-Headers für jeden gelisteten Header; ohne sie wird die Antwort blockiert, während `text/plain` bei derselben Richtlinie durchgeht.

GET, HEAD und POST sind safelisted Methoden: Sie passieren den Preflight auch ohne Eintrag in Access-Control-Allow-Methods. PUT, PATCH und DELETE müssen gelistet sein. Methoden- und Header-Namen werden ohne Rücksicht auf Groß- und Kleinschreibung verglichen: `post` und `x-test` passen.

Platzhalter, die mit Credentials nicht mehr gelten

`Access-Control-Allow-Methods: *` und `Access-Control-Allow-Headers: *` sind nur ohne Credentials Platzhalter. Eine Anfrage mit Credentials braucht ihre Methode und jeden Header wörtlich gelistet, und der Prüfer sagt das jetzt, statt dem Stern zu vertrauen.

Was der Prüfer nicht tut: Er sendet die Anfrage nicht und spielt keine Credentials nach, beurteilt keine Wertbeschränkungen von Headern (ein Authorization-Schema, ein Content-Type-Wert) und deckt keine Weiterleitungen, Null-Origins, Access-Control-Expose-Headers, Max-Age oder Vary ab.

Zuletzt verwendet: