CORS-Prüfer

Funktionsweise des CORS-Prüfers

Der CORS-Prüfer ist ein spezialisiertes Werkzeug, das Entwicklern hilft zu verstehen, ob ein Webbrowser eine bestimmte Cross-Origin-Anfrage (herkunftsübergreifende Anfrage) auf Basis der bereitgestellten HTTP-Antwort-Header und der spezifischen Anfragedetails zulassen würde.

Für die Überprüfung fügen Sie die HTTP-Antwort-Header in das Tool ein und definieren die Parameter der geplanten Anfrage: den Ursprung (Origin), die HTTP-Methode, die gewünschten Anfrage-Header sowie die Information, ob Anmeldedaten (Credentials) wie Cookies oder HTTP-Authentifizierungen übertragen werden. Das Tool analysiert diese Angaben lokal und gibt eine präzise Rückmeldung darüber, ob der Browser die Anfrage erlauben oder blockieren würde, und begründet diese Entscheidung detailliert anhand der geltenden CORS-Richtlinien.

Das Tool führt alle Prüfungen direkt in Ihrem Browser aus. Es erfolgt keine Übertragung oder Speicherung Ihrer Header und Anfragedaten auf den Servern von BroBroGo. Das Tool stellt keine Verbindung zu externen Servern her, liest keine URLs aus, setzt keine Cookies, prüft weder DNS noch TLS und nimmt keine Änderungen an Serverkonfigurationen vor.

Eingabeparameter und Validierung

Um eine präzise CORS-Prüfung durchzuführen, verarbeitet das Tool verschiedene Eingabefelder, die strengen Validierungsregeln unterliegen:

• Antwort zur Überprüfung: Sie wählen hier zwischen „Tatsächliche Reaktion“ und „Antwort vor dem Flug“.
• HTTP-Antwortheader: Ein Textfeld für die HTTP-Antwort-Header. Bei Preflight-Antworten muss auch die HTTP-Statuszeile eingefügt werden. Die Eingabe ist auf maximal 200.000 Zeichen begrenzt.
  • Fehler bei leerer Eingabe: „Fügen Sie vor der Überprüfung HTTP-Antwortheader ein.“
  • Fehler bei Überschreitung des Limits: „Diese Resonanz ist ungewöhnlich groß. Behalten Sie es unter den Zeichen ‹max›.“
  • Fehler bei ungültiger Zeilenstruktur: „Die Zeile ‹line› ist kein gültiger HTTP-Header oder keine gültige Statuszeile.“
  • Fehler bei ungültigem Header-Namen: „Zeile ‹line› enthält einen ungültigen HTTP-Headernamen.“
• Herkunft anfordern: Das Textfeld erwartet das Schema, den Host und optional den Port des anfragenden Ursprungs (z. B. https://app.example.com). Es muss sich um einen reinen Ursprung oder den Wert null handeln; Pfadangaben, Query-Parameter oder Anmeldedaten in der URL sind unzulässig.
  • Fehler bei ungültigem Ursprung: „Geben Sie einen Ursprung mit nur einem Schema, einem Host und einem optionalen Port ein, z. B. https://app.example.com.“
• Angeforderte Methode: Das Textfeld für die HTTP-Methode der Anfrage.
  • Fehler bei ungültigem Token: „Geben Sie ein gültiges HTTP-Methoden-Token ein.“
  • Fehler bei blockierten Methoden: „Browser erlauben die Methode ‹method› in fetch-Anfragen nicht.“
• Angeforderte Header-Namen: Hier werden die Header-Namen eingetragen, die im Header Access-Control-Request-Headers gesendet werden, getrennt durch Kommas oder Zeilenumbrüche (z. B. Content-Type, Authorization).
  • Fehler bei ungültigem Header-Namen: „„‹header›“ ist kein gültiger HTTP-Anforderungsheadername.“
• Geben Sie Anmeldeinformationen an: Ein Umschalter (Toggle), der aktiviert werden muss, wenn die Anfrage Cookies oder HTTP-Authentifizierungen enthält.

Browser-Entscheidungen und Auswertung

Nach der Auswertung der eingegebenen Daten zeigt das Tool eine der folgenden Browser-Entscheidungen im Bereich „Browser-Entscheidung“ an:

• „Fügen Sie eine Antwort ein, um die Richtlinie CORS zu überprüfen.“ (Initialzustand bei leerer Eingabe).
• „Geben Sie eine Antwort und Anfragedetails ein und überprüfen Sie dann die CORS-Richtlinie.“ (Wenn unvollständige Daten vorliegen).
• „Zulässig durch die eingefügte CORS-Antwort.“
• „Blockiert durch die eingefügte CORS-Antwort.“
• „Die Header sind erfolgreich, aber der Preflight-Status ist unbekannt.“

Zusätzlich listet das Tool die geparsten Felder im Bereich „Geparste Zugriffskontrollfelder“ auf und liefert eine detaillierte Begründung für die Entscheidung.

CORS-Regeln und logische Edge Cases

Bei der Auswertung wendet das Tool die standardisierten CORS-Spezifikationen der Browser an, wobei besondere Edge Cases berücksichtigt werden:

Handhabung von Anmeldeinformationen (Credentials)

Wenn die Option für Anmeldeinformationen aktiviert ist, gelten verschärfte Sicherheitsregeln:

• Der Header Access-Control-Allow-Origin darf nicht den Platzhalter * enthalten. Ein Wildcard führt in diesem Szenario unweigerlich zur Blockierung der Anfrage.
• Der Header Access-Control-Allow-Credentials muss exakt den Wert true aufweisen. Fehlt dieser Header oder hat er einen anderen Wert, blockiert der Browser den Zugriff.
• Wildcards (*) in den Headern Access-Control-Allow-Methods und Access-Control-Allow-Headers verlieren bei Anfragen mit Anmeldeinformationen ihre Wildcard-Bedeutung und werden nicht als Freigabe für alle Methoden oder Header interpretiert.

Validierung von Access-Control-Allow-Origin

• Der Header Access-Control-Allow-Origin darf nur einen einzigen Ursprung oder * enthalten. Enthält er mehrere Werte oder ist er durch Kommas getrennt, wird er als ungültig eingestuft.

Besonderheiten beim Authorization-Header

• Der Header Authorization nimmt eine Sonderstellung ein: Er muss in Access-Control-Allow-Headers immer explizit namentlich aufgeführt werden. Selbst wenn keine Anmeldedaten gesendet werden und Access-Control-Allow-Headers: * definiert ist, deckt dieser Platzhalter den Authorization-Header im Browser nicht ab.

Preflight-Status und HTTP-Statuscodes

• Für eine erfolgreiche Preflight-Prüfung (OPTIONS-Anfrage) muss die Antwort einen erfolgreichen HTTP-Statuscode aus dem 2xx-Bereich aufweisen.
• Wird bei einer Preflight-Prüfung keine HTTP-Statuszeile in das Textfeld eingefügt, ist eine Überprüfung des Statuscodes nicht möglich, was zu einem unbestimmten Ergebnis führt.

Grenzen der statischen Analyse

Ein positives Prüfergebnis („Zulässig durch die eingefügte CORS-Antwort.“) ist eine rein statische Auswertung der von Ihnen bereitgestellten Header-Daten. Es garantiert nicht, dass die Live-Anfrage in einer echten Produktionsumgebung erfolgreich sein wird. Die Analyse kann folgende dynamische Faktoren nicht berücksichtigen:

• Vom Server initiierte HTTP-Weiterleitungen (Redirects).
• Zwischengespeicherte CORS-Antworten im Browser-Cache.
• Dynamische Änderungen der Serverkonfiguration oder IP-basierte Filterungen.
• Eingriffe durch installierte Browser-Erweiterungen, die Header modifizieren.
• Abweichungen in der tatsächlichen Antwort des Servers, die nach einem erfolgreichen Preflight-Check gesendet wird.

Häufig gestellte Fragen (FAQ)

Soll ich die eigentliche Antwort oder die Preflight-Antwort einfügen?
Verwenden Sie „Tatsächliche Antwort“, um zu prüfen, ob der Browsercode eine Antwort lesen kann. Verwenden Sie die Preflight-Antwort für die OPTIONS-Antwort, die eine spätere Methode und die angeforderten Header-Namen genehmigt.

Warum kann ein Platzhalter bei Anmeldeinformationen fehlschlagen?
Wenn Cookies oder HTTP-Authentifizierung enthalten sind, muss der zulässige Ursprung genau mit dem anfordernden Ursprung übereinstimmen. Auch Platzhalter für erlaubte Methoden und Header verlieren ihre Platzhalterbedeutung.

Beweist ein positives Ergebnis, dass die Live-Anfrage funktioniert?
Nein. Dieses Ergebnis deckt nur die eingefügte Antwort und die hier eingegebenen Anfragedetails ab. Weiterleitungen, zwischengespeicherte Antworten, sich ändernde Serverregeln, Browsererweiterungen und die tatsächliche Antwort nach einem Preflight können das Ergebnis immer noch verändern.