ForHosting KIT · Entwickler-Tools

CORS-Header prüfen

Dieses Prüfwerkzeug für CORS-Header untersucht die Antwort-Header, die den ursprungsübergreifenden Zugriff im Browser steuern.

● BetaKostenlos · im Browser

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

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. Eine Warnung kann dennoch vorliegen; auswertende Systeme sollten daher ebenfalls issue_count und issues prüfen. 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. Das Werkzeug erfasst die Kombination als wildcard_origin_with_credentials mit Fehlerstufe. 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. Das Werkzeug meldet daher missing_vary_origin, wenn ein bestimmter Ursprung erlaubt ist und Vary weder Origin noch den Platzhalter enthält. 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

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.

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.

Konfigurationsprüfungen automatisieren

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

Häufige Fragen

Was kostet die Prüfung?

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

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.

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.

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.

Vollständige KIT-Dokumentation lesen →