HTTP-Sicherheits-Header
Prüfen Sie, ob Ihre Website die richtigen HTTP-Sicherheits-Header konfiguriert hat.
So funktioniert der Header-Check
Das Tool sendet einen normalen HTTPS-GET-Request an die eingegebene URL und liest die Antwort-Header - dieselben Header, die jeder Browser erhält. Aus dem Seiteninhalt wird nichts geparst; Security-Header stehen vollständig in der HTTP-Antwort.
Anschließend suchen wir nach den Headern, die browserseitige Schutzmechanismen steuern: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options und Referrer-Policy. Jeder vorhandene Header erhöht den Score, fehlende werden mit einer Erklärung des offen bleibenden Risikos aufgelistet.
Da der Check Weiterleitungen folgt, spiegelt das Ergebnis die endgültige URL wider. Leitet Ihre Website von HTTP auf HTTPS oder von der Apex-Domain auf www um, gehören die angezeigten Header zum Ziel.
So lesen Sie die Ergebnisse
Der Score ist eine schnelle Orientierung, keine Zertifizierung. Was in der Praxis zählt:
- HSTS - weist Browser an, für Ihre Domain immer HTTPS zu verwenden. Ein max-age von mindestens einem halben Jahr ist gängige Praxis; fügen Sie includeSubDomains nur hinzu, wenn jede Subdomain HTTPS ausliefert.
- CSP - der stärkste Schutz gegen XSS, aber auch der am schwersten zu schreibende. Selbst eine einfache Policy, die Skriptquellen einschränkt, ist eine große Verbesserung gegenüber gar keiner.
- X-Content-Type-Options: nosniff und X-Frame-Options (oder die CSP-Direktive frame-ancestors) - günstige Einzeiler gegen MIME-Sniffing und Clickjacking.
Häufige Probleme
Header konfiguriert, aber als fehlend gemeldet. Ein Reverse-Proxy oder CDN vor Ihrer Anwendung kann Header entfernen oder überschreiben. Vergleichen Sie die Antwort per curl -I direkt gegen den Origin und gegen die öffentliche URL, um die Schicht zu finden, die ihn verwirft.
CSP vorhanden, aber wirkungslos. Content-Security-Policy-Report-Only protokolliert Verstöße, ohne etwas zu blockieren. Das ist zum Testen nützlich, bietet aber keinen Schutz - wechseln Sie zum erzwingenden Header, sobald Ihr Report-Log sauber ist.
Verschiedene Routen liefern unterschiedliche Header. In der Anwendungs-Middleware gesetzte Header gelten möglicherweise nicht für statische Dateien, die der Webserver direkt ausliefert, oder für Fehlerseiten. Testen Sie auch eine statische Asset-URL und eine 404-Seite.
Häufig gestellte Fragen
Welche Security-Header sollte jede Website haben?
Eine sinnvolle Basis: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy und Frame-Schutz über X-Frame-Options oder CSP frame-ancestors. APIs profitieren zusätzlich von Cache-Control: no-store bei sensiblen Antworten.
Wird der Header X-XSS-Protection noch benötigt?
Nein. Moderne Browser haben den von ihm gesteuerten XSS-Auditor entfernt, und in alten Browsern konnte der Header sogar Schwachstellen einführen. Verwenden Sie stattdessen eine strikte Content-Security-Policy.
Schützt HSTS schon den allerersten Besuch?
Nicht von allein - der Browser lernt die Regel erst aus der ersten HTTPS-Antwort. Um den ersten Besuch abzudecken, tragen Sie Ihre Domain in die HSTS-Preload-Liste ein (hstspreload.org) und verwenden Sie die preload-Direktive zusammen mit includeSubDomains.
Kann ein falscher Header meine Website kaputt machen?
Ja, zwei Klassiker: Eine zu strikte CSP blockiert Ihre eigenen Skripte oder Inline-Styles, und HSTS mit includeSubDomains bricht jede Subdomain, die noch reines HTTP nutzt. Führen Sie CSP zuerst im Report-Only-Modus ein und starten Sie HSTS mit kurzem max-age.
Header-Änderungen kontinuierlich verfolgen
ePulz.io benachrichtigt Sie, wenn sich ein Header ändert (zum Beispiel nach einem Deployment, das CSP versehentlich entfernt hat).
Mit ePulz.io starten →Über dieses Tool
Sicherheits-Header sagen dem Browser, wie er Ihre Besucher schützen soll. Dieser Audit zeigt, ob HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options und Referrer-Policy tatsächlich vorhanden sind, und bewertet das Ergebnis, damit Sie nach einem Deploy Lücken wie Clickjacking und MIME-Sniffing aufspüren.