Was dieses Tool prüft
- Strict-Transport-Security (HSTS) und max-age
- Content-Security-Policy und schwächende Direktiven
- X-Frame-Options oder frame-ancestors
- X-Content-Type-Options: nosniff
- Referrer-Policy
- Permissions-Policy
- Cross-Origin-Opener/Resource-Policy
- Versionsangaben in Server und X-Powered-By
So funktioniert es
- 01
Geben Sie eine Domain oder vollständige URL ein (https://beispiel.de/login).
- 02
Klicken Sie auf Analysieren; Weiterleitungen werden verfolgt und die Zielseite bewertet.
- 03
Setzen Sie für jeden Header den empfohlenen Wert aus den Hinweisen im Bericht.
Technische Details
Bewertung
HSTS und CSP wiegen am meisten, danach Clickjacking- und MIME-Schutz. Eine CSP mit 'unsafe-inline' oder 'unsafe-eval' ohne Nonces oder Hashes gilt als schwach.
Weiterleitungskette
Das Tool verfolgt Weiterleitungen einzeln und liest die Header der letzten Antwort. Die ganze Kette steht im Bericht, sodass Sie auch den Wechsel von HTTP zu HTTPS prüfen können.
CSP einführen
Veröffentlichen Sie CSP auf einer bestehenden Website zunächst als Content-Security-Policy-Report-Only, beobachten Sie die Verstoßberichte und schalten Sie dann in den erzwingenden Modus.
Häufige Fragen
Mit welchem Header sollte ich anfangen?
Am schnellsten wirken X-Content-Type-Options, X-Frame-Options und Referrer-Policy – je eine Zeile. HSTS setzen Sie, sobald alle Subdomains HTTPS können, CSP führen Sie mit Tests ein.
Warum prüfen Sie X-XSS-Protection nicht?
Moderne Browser unterstützen ihn nicht mehr, und er konnte teils neue Probleme verursachen. Das richtige Mittel gegen XSS ist heute Content-Security-Policy.
Wo setze ich die Header?
Im Webserver (nginx, Apache, IIS), im CDN (z. B. Cloudflare Transform Rules) oder im Framework (Next.js, Express, Laravel). Eine zentrale Ebene hält sie konsistent.
Warum ist eine Version im Server-Header ein Problem?
Eine genaue Version erleichtert gezielte Angriffe auf bekannte Schwachstellen dieser Version. Sie zu verbergen ist eine kleine, einfache Verbesserung.