HTTP-Sicherheitsheader-Prüfer

Prüfe kopierte HTTP-Response-Header, ohne sie an einen Scan-Dienst zu senden. Der Checker bewertet acht nützliche Konfigurationsbereiche, unterscheidet fehlende Header von schwachen Werten und behält die Rohdaten im Browser. Er ruft keine URL ab, untersucht keinen Response-Body und beweist nicht, dass eine Website sicher ist.

So prüfst du Response-Header

  1. 1

    Endgültige Antwort erfassen

    Öffne den Netzwerkbereich des Browsers oder verwende einen vertrauenswürdigen HTTP-Client, folge Weiterleitungen und kopiere die Header der zu prüfenden Antwort.

  2. 2

    Rohen Headerblock einfügen

    Verwende pro Zeile ein Paar aus Name und Wert. Eine Statuszeile wie HTTP/2 200 wird akzeptiert, aber nicht ausgewertet.

  3. 3

    Semantische Prüfungen lesen

    Die Zustände Bestanden, Prüfen und Fehlt beruhen auf erkannten Werten und nicht nur auf dem Vorhandensein eines Headernamens.

  4. 4

    Änderungen im Kontext testen

    Führe Richtlinien vorsichtig ein und teste die echte Seite erneut, da CSP, COEP und Permissions-Policy benötigte Funktionen blockieren können.

Was die lokale Bewertung aussagt und was nicht

Die Punktzahl ist eine Konfigurationscheckliste, kein Schwachstellenscan und keine Zertifizierung. Ein erkannter starker Wert erhält zwei Punkte, ein prüfbedürftiger Wert einen Punkt und ein fehlender oder ungültiger Schutz keinen Punkt.

Enthaltene Prüfungen

Bereich Starkes Signal dieses Checkers Wichtige Grenze
HSTS Positives max-age von mindestens 180 Tagen mit includeSubDomains HSTS nur über HTTPS senden und HTTPS für alle erfassten Subdomains sicherstellen
CSP Eine durchgesetzte Richtlinie beschränkt Skriptquellen ohne *, 'unsafe-inline' oder 'unsafe-eval' Eine sinnvolle CSP ist anwendungsspezifisch und muss getestet werden
Einbettung Durchgesetztes CSP frame-ancestors oder das ältere X-Frame-Options: DENY/SAMEORIGIN Unterstützende Browser geben frame-ancestors Vorrang
MIME X-Content-Type-Options: nosniff Der Server muss weiterhin korrekte Content-Type-Werte liefern
Referrer Eine Richtlinie wie strict-origin-when-cross-origin oder no-referrer Die Richtlinie muss zu Analyse- und Datenschutzanforderungen passen
Browserfunktionen Permissions-Policy sperrt mindestens eine Funktion mit feature=() und enthält keine Wildcard-Freigabe Der Checker kann nicht beurteilen, ob jede Freigabeliste zur Anwendung passt
Cross-Origin-Isolierung COOP: same-origin und erkannte COEP-Werte Diese Header können Pop-ups oder Cross-Origin-Ressourcen beeinträchtigen

Der veraltete Filter X-XSS-Protection bringt keine Punkte. Aktuelle Empfehlungen bevorzugen CSP; ein Wert ungleich null erscheint als Hinweis. Serverangaben wie Server und X-Powered-By sind ebenfalls nur Hinweise und kein Beweis für eine Schwachstelle.

Die technischen Regeln orientieren sich am OWASP HTTP Headers Cheat Sheet, an W3C CSP Level 3 und an RFC 6797. Ein eingefügter Block zeigt nicht, ob die Header über HTTPS kamen, das Zertifikat gültig ist, Weiterleitungen die Richtlinie verändert haben oder der Browser eine andere zwischengespeicherte Antwort erhielt.

Datenschutz und Funnel-Speicherung

Parsing und Bewertung laufen in diesem Browser. Rohheader werden weder zu Livewire-Eigenschaften noch in die URL geschrieben. Im Funnel verweist eine zufällige Kennung auf einen sessionStorage-Datensatz, der 30 Minuten nach seiner Erstellung abläuft. Ein erneuter Aufruf verlängert die Frist nicht. Höchstens drei aktuelle Datensätze bleiben erhalten. Bei einem Speicherfehler stoppt der Funnel, anstatt die Header anderswohin zu senden.

Häufig gestellte Fragen

Nein. Das Tool kontaktiert die Zielseite nicht. Kopiere die endgültigen Response-Header aus den Entwicklertools oder einem vertrauenswürdigen HTTP-Client und füge diese Zeilen ein.

Das Vorhandensein allein reicht nicht. HSTS mit max-age=0 deaktiviert beispielsweise HSTS, und X-Content-Type-Options erkennt nur den Wert nosniff an.

Nein. Die Bewertung deckt nur eine begrenzte Headercheckliste ab. Anwendungscode, Anmeldung, TLS-Konfiguration, Abhängigkeiten und Serverschwachstellen werden nicht getestet.

Content-Security-Policy-Report-Only sammelt Meldungen, erzwingt aber keine Einschränkungen. Sie hilft beim Rollout, ist allein jedoch kein aktiver Schutz.

CSP frame-ancestors ist die moderne Regel und hat in unterstützenden Browsern Vorrang. X-Frame-Options kann als kompatibler Fallback für ältere Clients bleiben.

Der Browserfilter ist veraltet und kann Probleme verursachen. Moderne Empfehlungen setzen auf eine gut entworfene CSP und lassen den Header meist weg oder setzen ihn auf 0.

Nicht automatisch. Cross-Origin-Isolierung ermöglicht bestimmte Funktionen, kann aber Integrationen, Pop-ups oder Ressourcen blockieren. Prüfe vor der Bereitstellung die Anforderungen der Anwendung.

Nein. Die Analyse bleibt im Browser. Im Funnel liegt der Rohblock nur vorübergehend im sessionStorage unter einer nichtssagenden Kennung mit fester Laufzeit von 30 Minuten.

Verwandte Tools