Sicherheits-Header-Prüfer

Der Security-Headers-Checker ist ein kostenloses Online-Tool, in das du HTTP-Antwort-Header einfügst, um die Sicherheitskonfiguration mit Bewertung, CSP-/HSTS-/Cookie-Prüfungen und einer Analyse der Cross-Origin-Richtlinien zu untersuchen. Es läuft vollständig in deinem Browser, ohne Installation oder Anmeldung.

CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP, X-XSS-Protection, Cache-Control und die Sicherheits-Flags von Set-Cookie.

Jeder Header wird nach Schweregrad gewichtet. Eine korrekte Konfiguration erhält die volle Gewichtung, eine fehlerhafte einen Teil und eine fehlende null. Die Gesamtsumme wird auf A+ bis F abgebildet.

Ja. Die gesamte Analyse läuft in deinem Browser. Es werden keine Daten an einen Server gesendet.

Ja, der Security-Headers-Checker ist zu 100 % kostenlos – ohne Registrierung, ohne versteckte Gebühren und ohne Nutzungsbeschränkungen. Die gesamte Verarbeitung erfolgt lokal in deinem Browser und gewährleistet vollständige Privatsphäre.

Ja, der Security-Headers-Checker ist vollständig responsiv und funktioniert auf Smartphones und Tablets. Du kannst ihn auf jedem Gerät mit einem modernen Webbrowser nutzen – ohne App-Download.

Es ist kein Konto und keine Registrierung erforderlich. Öffne einfach den Security-Headers-Checker in deinem Browser und beginne sofort mit der Nutzung. Es gibt keine Anmeldeschranken oder Nutzungsbeschränkungen.

Gib einfach deine Daten in das vorgesehene Feld ein, passe die Einstellungen nach Belieben an, und das Tool verarbeitet sie sofort. Anschließend kannst du das Ergebnis in die Zwischenablage kopieren oder herunterladen.

Der Security-Headers-Checker funktioniert in allen modernen Browsern, darunter Chrome, Firefox, Safari, Edge und Opera. Für das beste Erlebnis verwende die neueste Version deines bevorzugten Browsers.

Es gibt zwei schnelle Wege. Über die Kommandozeile führen Sie curl -I https://example.com aus und kopieren die Antwort, die jeden Header in einer eigenen Zeile ausgibt. Über den Browser öffnen Sie die DevTools, wechseln zum Network-Tab, laden die Seite neu, klicken auf die oberste Dokumentanfrage und kopieren den Abschnitt Response Headers. In beiden Fällen fügen Sie die Zeilen im Format Key: Value ein, einen Header pro Zeile. Die vorangestellte Statuszeile wie HTTP/2 200 OK darf ruhig mit eingefügt werden, sie wird automatisch übersprungen. Da curl und DevTools die Seite wie ein echter Client anfragen, erfassen sie genau die Header, die ein Browser erhält, einschließlich Set-Cookie und Cache-Direktiven. Wenn Sie nur sehen möchten, wie die Bewertung funktioniert, laden Sie stattdessen das eingebaute Secure- oder Weak-Beispiel und werfen Sie einen Blick auf die Aufschlüsselung pro Header.

Ein starker HSTS-Header weist Browser an, für lange Zeit ausschließlich über HTTPS zu verbinden und dabei jede Subdomain einzuschließen. Der Checker prüft drei Dinge: eine max-age von mindestens 31536000 Sekunden (ein Jahr), die Direktive includeSubDomains, damit Subdomains dieselbe HTTPS-only-Regel übernehmen, sowie das preload-Flag. Eine kurze max-age, etwa nur wenige Tage, lässt ein langes Zeitfenster offen, in dem ein Downgrade- oder Man-in-the-Middle-Angriff HTTPS aushebeln kann, weshalb das Tool alles unter einem Jahr markiert und den Wert in Tagen anzeigt. Das preload-Flag ist wichtig, weil es Ihre Domain für die HSTS-Preload-Listen qualifiziert, die in Chrome, Firefox und Safari eingebettet sind und HTTPS bereits beim allerersten Besuch eines Nutzers erzwingen. Fügen Sie Ihre Header ein, um genau zu sehen, welcher dieser drei Bausteine Ihrem HSTS fehlt.

Beide schützen vor Clickjacking, indem sie steuern, ob Ihre Seite in einem iframe eingebettet werden kann, doch frame-ancestors ist der moderne Nachfolger. X-Frame-Options ist älter und unterstützt zuverlässig nur DENY und SAMEORIGIN; sein Wert ALLOW-FROM gilt als veraltet und wird von Chrome, Firefox und Safari ignoriert, weshalb der Checker ALLOW-FROM als falsch konfiguriert markiert. Die frame-ancestors-Direktive der Content-Security-Policy erfüllt denselben Zweck, ist aber flexibler: Sie akzeptiert eine Liste erlaubter Ursprünge und wird in aktuellen Browsern durchgängig respektiert. Bewährte Praxis ist es, frame-ancestors 'none' oder eine spezifische Allow-Liste in Ihrer CSP zu setzen und X-Frame-Options: SAMEORIGIN nur noch als Fallback für sehr alte Browser beizubehalten. Das Tool prüft zusätzlich separat, ob die frame-ancestors-Direktive in Ihrer CSP fehlt, und markiert dies gesondert. Fügen Sie Ihre Header ein, um zu bestätigen, dass Ihr Clickjacking-Schutz beide Ebenen korrekt abdeckt.

Das wirkt zunächst widersprüchlich, aber 0 ist tatsächlich der korrekte moderne Wert. X-XSS-Protection aktivierte einen veralteten XSS-Auditor, den ältere Browser eingebaut hatten, doch dieser Auditor hatte bekannte Umgehungsmöglichkeiten und konnte sogar selbst missbraucht werden, um Teile einer Seite gezielt zu deaktivieren oder preiszugeben, ob bestimmte Inhalte vorhanden waren. Moderne Browser haben ihn vollständig entfernt, sodass ein Wert wie 1; mode=block nichts Sinnvolles mehr bewirkt und eine trügerische Sicherheit vermitteln kann. Das explizite Senden von X-XSS-Protection: 0 schaltet jedes verbliebene Legacy-Verhalten in Browsern ab, die den Header noch erkennen. Der eigentliche Schutz vor Cross-Site-Scripting ist heute eine strikte Content-Security-Policy, die Inline- und nicht vertrauenswürdige Skripte blockiert — deshalb gewichtet das Tool CSP stark und behandelt diesen Header als veraltet. Fügen Sie Ihre Header ein, um zu sehen, ob Ihre CSP diese Aufgabe zuverlässig übernimmt.

Der Checker untersucht jeden Set-Cookie-Header auf drei Flags: Secure, HttpOnly und SameSite. Secure stellt sicher, dass das Cookie nur über HTTPS gesendet wird, sodass es auf einer unverschlüsselten Verbindung nicht abgefangen werden kann. HttpOnly verbirgt das Cookie vor JavaScript und verhindert so, dass ein XSS-Payload ein Sitzungstoken über document.cookie stiehlt. SameSite steuert, ob das Cookie bei Cross-Site-Anfragen mitgesendet wird; Strict oder Lax hilft, Cross-Site-Request-Forgery zu verhindern, während None das Vorhandensein von Secure voraussetzt. Sitzungs- und Authentifizierungs-Cookies sollten alle drei Flags tragen, und das Tool markiert jedes Cookie, dem eines davon fehlt, damit Sie erkennen, welche Nutzer einem Risiko aussetzen. Da alles im Browser geparst wird, können Sie bedenkenlos authentifizierte Antworten mit echten Set-Cookie-Werten einfügen. Fügen Sie Ihre Header ein, um eine Liste pro Cookie zu erhalten, welche Flags gesetzt sind und welche fehlen.