ForHosting KIT · Entwickler-Tools

CORS-Header prüfen

Eine Antwort, die app.example.com mit Anmeldedaten erlaubt und Origin im Vary-Header nennt, besteht mit 0 Befunden. Fügen Sie die erfassten Header ein und sehen Sie sofort, ob ein Platzhalter mit Anmeldedaten kombiniert ist oder ein Cache-Signal fehlt. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Dieses Prüfwerkzeug für CORS-Header untersucht die Antwort-Header, die den ursprungsübergreifenden Zugriff im Browser steuern. Fügen Sie einen Headerblock ein, um Access-Control-Allow-Origin zu bestätigen, die unsichere Verbindung eines Platzhalters mit Zugangsdaten zu erkennen und ein fehlendes Vary: Origin bei einem bestimmten erlaubten Ursprung zu melden. Das Ergebnis ist deterministisch und erläutert jeden Befund. Damit eignet es sich für Bereitstellungsprüfungen, Vorfallanalysen, automatisierte Kontrollen und die regelmäßige Absicherung von APIs, ohne eine Anfrage an den Zielserver zu senden.

Verstehen Sie das Ergebnis als gezielte Prüfung

Kopieren Sie zunächst die Antwort-Header genau so, wie der Browser oder Kommandozeilen-Client sie empfangen hat, mit einem Paar aus Name: Wert pro Zeile. Headernamen werden ohne Beachtung der Groß- und Kleinschreibung verglichen; durch Kommas getrennte Vary-Werte gelten als einzelne Einträge. Access-Control-Allow-Origin ist erforderlich, weil ohne diesen Header keine CORS-Antwortregel bewertet werden kann.

Sein Fehlen erzeugt deshalb einen Eingabefehler statt eines unklaren Berichts. Ein erfolgreicher Bericht liefert den normalisierten erlaubten Ursprung, den Status der Zugangsdaten, die Abhängigkeit der Antwort von Origin und eine geordnete Befundliste. Das Feld valid bedeutet, dass kein Fehlerbefund erkannt wurde.

Der enge Umfang ist beabsichtigt: Er liefert belastbare Fakten zu zwei häufigen Fehlkonfigurationen, ohne das gesamte Berechtigungsmodell einer Anwendung als sicher auszugeben. Bewahren Sie die ursprüngliche Antwort und den Anfrageursprung zusammen mit dem Ergebnis auf, wenn die Prüfung Teil eines Auditnachweises ist.

Ordnen Sie Platzhalter und Anfragen mit Zugangsdaten ein

Access-Control-Allow-Origin: * ist für wirklich öffentliche Ressourcen ohne Zugangsdaten zweckmäßig, da jeder anfragende Ursprung die Antwort lesen darf. Der Wert darf nicht mit Access-Control-Allow-Credentials: true kombiniert werden. Browser lehnen diese Verbindung beim CORS-Zugriff mit Zugangsdaten ab; häufig zeigt sie zudem, dass die beabsichtigte Vertrauensgrenze des Servers nicht korrekt ausgedrückt wurde.

Die Lösung besteht nicht darin, jeden eingehenden Origin ungeprüft zurückzugeben. Legen Sie vertrauenswürdige Ursprünge fest, gleichen Sie den Anfrage-Origin mit einer ausdrücklichen Positivliste ab und geben Sie nur nach einem Treffer genau einen genehmigten Ursprung aus. Werden Cookies oder andere Umgebungszugangsdaten nicht benötigt, deaktivieren Sie deren Unterstützung und behalten Sie die öffentliche Platzhalterregel bei.

CORS steuert lediglich, ob Browserskripte eine Antwort lesen dürfen; es ersetzt weder Authentifizierung und Autorisierung noch Schutz vor Anfragefälschung oder eine Firewall. Prüfen Sie Cookieattribute, Berechtigungen, Methoden, freigegebene Header und Preflight-Verhalten gesondert.

Halten Sie gemeinsame Caches mit Vary: Origin korrekt

Wählt ein Server Access-Control-Allow-Origin anhand des Anfrage-Headers Origin aus, hängt die Antwortdarstellung faktisch von diesem Header ab. Vary: Origin teilt Browsern, Reverse-Proxys und Auslieferungsnetzen mit, dass Antworten für verschiedene Ursprünge nicht austauschbar sind. Ohne diesen Hinweis kann ein Cache eine Antwort mit dem erlaubten Ursprung eines Mandanten für eine andere Anfrage wiederverwenden.

Das verursacht sporadische Fehler und kann Annahmen der Sicherheitsregel für zwischengespeicherte Inhalte unterlaufen. Origin wird sowohl in einer kommaseparierten Vary-Zeile als auch über wiederholte Vary-Header hinweg erkannt. Der Befund bleibt eine Warnung, weil ein eingefügter Antwortblock nicht erkennen lässt, ob der Ursprung für alle Anfragen gleich bleibt oder Caching an anderer Stelle deaktiviert ist.

Prüfen Sie die tatsächliche Auswahllogik des Servers und seine Cache-Anweisungen, bevor Sie die Produktion ändern. Wird der Ursprung nach Prüfung gegen eine Positivliste dynamisch zurückgegeben, ist Origin in Vary gewöhnlich das klarste und sicherste Cache-Signal.

Anwendungsfälle

CORS-Fehler im Browser untersuchen

Wandeln Sie erfasste Antwort-Header in klare Befunde um, wenn sich eine Oberfläche je nach Ursprung oder Cachepfad anders verhält.

Häufige Fragen

Warum ist fehlendes Access-Control-Allow-Origin ein Fehler?

Dieser Header bildet die Grundlage einer CORS-Antwortregel. Ohne ihn gibt es keinen erlaubten Ursprungswert, den diese gezielte Prüfung bewerten könnte.

Ist Access-Control-Allow-Origin: * immer unsicher?

Nein. Für manche öffentlichen Ressourcen ohne Zugangsdaten ist es passend. Der Fehler setzt sowohl den Platzhalter als auch auf true gesetzte Zugangsdaten voraus.

Warum ist fehlendes Vary: Origin nur eine Warnung?

Die Antwort allein zeigt nicht, ob sich der Ursprung zwischen Anfragen ändert oder ein Vermittler sie speichern kann. Die Warnung fordert zur Prüfung dieses Umfelds auf.

Verbindet sich die Prüfung mit meinem Server?

Nein. Sie liest nur die Header, die Sie einfügen, und sendet nichts an die Website, von der sie stammen. Gehört die Prüfung zu einem Audit, bewahren Sie die ursprüngliche Antwort und den anfragenden Ursprung mit dem Ergebnis auf.

Bedeutet ein Ergebnis ohne Befund, dass meine Website sicher ist?

Nein. CORS legt nur fest, ob Skripte im Browser eine Antwort lesen dürfen; es ist weder Anmeldung noch Rechteprüfung, Schutz vor gefälschten Anfragen oder Firewall. Prüfen Sie Cookies, erlaubte Methoden und Vorabprüfungen separat.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/security/cors-header-check

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/security/cors-header-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"headers":"Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"}'

const res = await fetch("https://api.kit.forhosting.com/security/cors-header-check", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "headers": "Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/security/cors-header-check",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "headers": "Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/cors-header-check", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"headers":"Access-Control-Allow-Origin: https://app.example.com\\nAccess-Control-Allow-Credentials: true\\nVary: Accept-Encoding, Origin"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"headers":"Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/cors-header-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "headers": "Access-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\nVary: Accept-Encoding, Origin"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "security.cors_header_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Verstehen Sie das Ergebnis als gezielte Prüfung

Eine Warnung kann dennoch vorliegen; auswertende Systeme sollten daher ebenfalls issue_count und issues prüfen.

Ordnen Sie Platzhalter und Anfragen mit Zugangsdaten ein

Das Werkzeug erfasst die Kombination als wildcard_origin_with_credentials mit Fehlerstufe.

Halten Sie gemeinsame Caches mit Vary: Origin korrekt

Das Werkzeug meldet daher missing_vary_origin, wenn ein bestimmter Ursprung erlaubt ist und Vary weder Origin noch den Platzhalter enthält.

Integrationsbeispiele

Eine API-Bereitstellung prüfen

Fügen Sie Header einer Testantwort ein und erkennen Sie vor der Freigabe unsichere Einstellungen für Zugangsdaten oder Cache-Varianten.

Konfigurationsprüfungen automatisieren

Verarbeiten Sie deterministische Headerblöcke über die API in CI und lassen Sie Richtlinienprüfungen bei Fehlerbefunden scheitern.

Technische Fragen

Was kostet die Prüfung?

Die Browserversion läuft lokal; jede API-Anfrage kostet $0.002.

Beweist diese Prüfung, dass ein Endpoint sicher ist?

Nein. Sie prüft zwei häufige CORS-Headerfehler. Authentifizierung, Autorisierung, Cookies, Preflight, erlaubte Methoden und Schutz vor Anfragefälschung benötigen eigene Prüfungen.

Wird bei Headernamen die Großschreibung beachtet?

Nein. HTTP-Headernamen und die maßgeblichen Anweisungselemente werden ohne Beachtung der Groß- und Kleinschreibung verglichen.

Vollständige KIT-Dokumentation lesen →

CORS-Header prüfen

Im Browser ausführen – kostenlos

Verstehen Sie das Ergebnis als gezielte Prüfung

Ordnen Sie Platzhalter und Anfragen mit Zugangsdaten ein

Halten Sie gemeinsame Caches mit Vary: Origin korrekt

Anwendungsfälle

CORS-Fehler im Browser untersuchen

Häufige Fragen

Verwandte Tools

Für Entwickler — API-Zugang

Endpunkt

Aufruf aus Ihrem Stack

Beispiel-Anfrage

Beispiel-Antwort

Preis

Fehler

Technische Hinweise

Verstehen Sie das Ergebnis als gezielte Prüfung

Ordnen Sie Platzhalter und Anfragen mit Zugangsdaten ein

Halten Sie gemeinsame Caches mit Vary: Origin korrekt

Integrationsbeispiele

Eine API-Bereitstellung prüfen

Konfigurationsprüfungen automatisieren

Technische Fragen

danke