Security-Header-Check

Testen Sie die HTTP Security Header einer beliebigen Seite: CSP, HSTS, Framing, Cookies, die Weiterleitung von HTTP, Skript-Integrität und CORS. Zu jeder Lücke gibt es die genaue Änderung, zu jedem Ergebnis einen Link zum Teilen. Kostenlos, ohne Konto.

Was sind HTTP Security Header?

HTTP Security Header sind Anweisungen, die ein Webserver mit jeder Antwort mitschickt. Sie schalten Schutzfunktionen ein, die der Browser bereits besitzt: aus welchen Quellen Skripte laufen dürfen, ob die Website jemals wieder über unverschlüsseltes HTTP geladen werden darf und ob eine fremde Website sie in einem Frame anzeigen darf. Fehlen sie, greift der Browser auf freizügige Voreinstellungen zurück.

Der reportedIP Security-Header-Check ruft eine Seite so ab wie ein Browser und liest diese Header zusammen mit den Cookies, der Weiterleitung von http:// und den Skript-Tags der Seite aus. Das Ergebnis erhält eine Note von A+ bis F, und jeder Befund nennt die Änderung, die ihn behebt.

Was der Check prüft

Dreizehn Prüfungen, sortiert nach dem, was sie verhindern. Das Gewicht ist der Anteil der Prüfung an der Punktzahl; Prüfungen mit Gewicht 0 werden angezeigt, aber nicht bewertet.

Prüfung	Was sie verhindert	Gewicht
`Content-Security-Policy`	Eingeschleuste Skripte, die mit den Rechten der Seite laufen (Cross-Site-Scripting)	25
`Strict-Transport-Security (HSTS)`	Die erste Anfrage eines Besuchs geht unverschlüsselt raus und kann umgeleitet werden	20
`X-Frame-Options / frame-ancestors`	Clickjacking: eine fremde Website lädt die Seite in einem unsichtbaren Frame	15
`X-Content-Type-Options`	Der Browser rät den Dateityp und führt einen Upload als Skript aus	15
`HTTP → HTTPS redirect`	Wer nur die Domain eintippt, bleibt auf unverschlüsseltem HTTP	10
`Cookies (Secure, HttpOnly, SameSite)`	Sitzungs-Cookies gehen über HTTP raus oder werden von eingeschleusten Skripten gelesen	10
`Subresource Integrity (SRI)`	Ein kompromittiertes CDN verändert die Skripte, die Ihre Seite lädt	10
`Referrer-Policy`	Vollständige URLs samt Query-String landen bei fremden Websites	10
`Permissions-Policy`	Eingebetteter Code fragt nach Kamera, Mikrofon oder Standort	10
`CORS (Access-Control-Allow-Origin)`	Fremde Websites lesen die Seite mit der Anmeldung des Besuchers	5
`Server / X-Powered-By`	Genaue Versionsnummern bringen die Website auf die Liste eines Scanners	5
`COOP / COEP / CORP`	Angezeigt, nicht bewertet: nur für Cross-Origin-Isolation nötig	0
`TLS certificate`	Angezeigt, nicht bewertet: Aussteller, Ablaufdatum und Protokoll des Zertifikats	0

Hintergrund zu jedem Header: das OWASP HTTP Headers Cheat Sheet und die Header-Referenz von MDN.

Wie Punktzahl und Note berechnet werden

Jede Prüfung erhält zwischen 0 und 100 Punkten, multipliziert mit ihrem Gewicht. Eine fehlende Content-Security-Policy kostet deshalb fünfmal so viel wie ein Server, der seine Version verrät, und das entspricht dem Schaden, den beides zulässt. Eine Prüfung, die nicht zutrifft, fällt aus der Rechnung heraus, statt null Punkte zu bekommen: HSTS auf einer Seite über unverschlüsseltes HTTP, Cookie-Flags auf einer Seite ohne Cookies, die Weiterleitung, wenn auf Port 80 niemand antwortet.

Die Note folgt den Buchstabengrenzen des HTTP Observatory von Mozilla: A ab 90 Punkten, A- ab 85, B+ ab 80, B ab 70, B- ab 65, C+ ab 60, C ab 50, C- ab 45, D+ ab 40, D ab 30, D- ab 25, darunter F. Für A+ braucht es mindestens 95 Punkte und keinen fehlerhaften Befund. Das Observatory erreicht A+ über Bonuspunkte oberhalb von 100 und gewichtet manche Befunde anders, deshalb können beide Noten für dieselbe Website auseinanderliegen.

Wo eine Checkliste falsch liegt

frame-ancestors ersetzt X-Frame-Options

Setzt die Content-Security-Policy frame-ancestors, ist X-Frame-Options nicht mehr nötig. Die Direktive ist der festgelegte Nachfolger, jeder aktuelle Browser beachtet sie, und sie kann die Websites benennen, die die Seite einbetten dürfen. Zwei Fälle zählen nicht: eine Policy, die nur als Report-Only gesendet wird und nichts blockiert, und frame-ancestors in einem Meta-Tag, das Browser ignorieren.

max-age=0 ist schlechter als gar kein HSTS

Der Wert weist den Browser an zu vergessen, dass die Website je nur über HTTPS erreichbar war (RFC 6797, Abschnitt 6.1.1). Eine Checkliste sieht einen vorhandenen Header und hakt ihn ab; dieser Check wertet ihn als fehlerhaft.

HSTS über unverschlüsseltes HTTP bewirkt nichts

Browser müssen den Header in einer unverschlüsselten Antwort ignorieren (RFC 6797, Abschnitt 8.1). Der Check lässt ihn deshalb aus der Rechnung heraus, statt Punkte zu vergeben oder abzuziehen.

Ein doppelt gesendeter Header ist nicht immer ein Fehler

Oft setzen Webserver und CMS denselben Header beide. Identische Kopien werden als ein Wert gelesen, der Check akzeptiert sie und weist nur auf die Dopplung hin. Bei HSTS zählt nur die erste Kopie (RFC 6797, Abschnitt 8.1): Enthält die zweite includeSubDomains und die erste nicht, gilt die schwächere. X-Frame-Options mit DENY und SAMEORIGIN zugleich führt dazu, dass Browser jeden Frame ablehnen, auch die eigenen der Website.

So arbeitet das Tool und hier liegen seine Grenzen

Die Adresse wird mit einem normalen GET abgerufen, nicht mit HEAD, weil etliche Server, Proxys und Firewalls auf HEAD mit weniger Headern antworten. Bis zu drei Weiterleitungen werden verfolgt. Die Anfrage trägt einen Origin-Header von einer Domain, die niemand freigeben würde; eine Seite, die ihn trotzdem zulässt, übernimmt also jeden anfragenden Origin. Eine zweite Anfrage geht an http:// auf demselben Host, um zu sehen, wohin die erste Weiterleitung führt, und ein TLS-Handshake auf Port 443 liest das Zertifikat.

Von der Seite selbst werden nur die ersten 256 KB HTML gelesen, für Skript-Tags und eine Content-Security-Policy im Meta-Tag. Vom Inhalt wird nichts gespeichert. Cookies werden auf Namen und Flags reduziert, bevor irgendetwas gespeichert oder angezeigt wird; ihre Werte werden verworfen.

Ergebnisse bleiben eine Stunde gespeichert. Jeder Check bekommt einen Link der Form /security-headers/?url=example.com, der das gespeicherte Ergebnis zeigt, ohne die Website erneut abzurufen, und ein gespeichertes Ergebnis zählt nicht gegen das Tageslimit. Erneut prüfen holt ein frisches Ergebnis, sobald das gespeicherte eine Minute alt ist.

Der Check läuft von unserem Server aus. Eine Website, die ihre Header nach Land, User-Agent oder Anmeldestatus variiert, kann Ihnen deshalb anders antworten. Gelesen wird nur eine Seite: Header aus der Webserver-Konfiguration gelten meist überall, eine Anwendung kann sie aber pro Route ergänzen oder weglassen, deshalb lohnt es sich, die Login- oder Checkout-Seite eigens zu prüfen. Skript-Tags, die JavaScript erst später einfügt, sieht der Check nicht. Ob eine Policy weit genug ist, damit die Website funktioniert, kann das Tool nicht beurteilen, und beim TLS meldet es die Version, die der Server gewählt hat, nicht, ob ältere noch angenommen werden.

Häufig gestellte Fragen

Wie füge ich einer Website Security Headers hinzu?

Setzen Sie sie an genau einer Stelle, möglichst nah am Besucher: im Webserver, im Reverse Proxy oder im CDN. In nginx geschieht das mit add_header und dem Parameter always, damit auch Fehlerseiten sie tragen; ein location-Block mit eigenem add_header verwirft alle Header, die er von oben geerbt hätte. In Apache ist es Header always set aus mod_headers. Ein CMS-Plugin geht ebenfalls, dann sollte der Webserver denselben Header aber nicht noch einmal senden. Die Content-Security-Policy starten Sie am besten im Report-Only-Modus.

Welcher Security Header ist am wichtigsten?

„Content-Security-Policy“, und zwar mit großem Abstand. Diese Richtlinie legt fest, woher Skripte, Styles und Frames stammen dürfen, und entscheidet darüber, ob ein eingeschleustes Skript ausgeführt oder abgelehnt wird. „Strict-Transport-Security“ steht an zweiter Stelle, da diese Richtlinie die unverschlüsselte erste Anfrage verhindert. Die übrigen Einstellungen sind ebenfalls sinnvoll, doch keine von ihnen beeinflusst den Ausgang eines Angriffs so entscheidend wie diese beiden.

Benötige ich „X-Frame-Options“ noch?

Nicht, wenn Ihre „Content-Security-Policy“ die Anweisung „frame-ancestors“ enthält. Diese Anweisung ersetzt den älteren Header, und jeder aktuelle Browser berücksichtigt sie. Es schadet zwar nicht, beide beizubehalten, doch ein Prüfprogramm, das den älteren Header auf einer Website mit einer korrekten Richtlinie als fehlend markiert, wiederholt damit Empfehlungen, die bereits zehn Jahre alt sind.

Warum werden bei dieser Überprüfung einige Kopfzeilen mit Null bewertet?

Denn nicht jede Feststellung gilt für jede Website. Die Header zur Cross-Origin-Isolation sind nur für Seiten von Bedeutung, die bestimmte Browserfunktionen benötigen, und eine Website, die diese nie benötigt hat, hat keinen Fehler begangen, indem sie diese weggelassen hat. Das TLS-Zertifikat wird ebenfalls angezeigt, doch ein fehlerhaftes Zertifikat stoppt den Browser bereits, bevor überhaupt ein Header gelesen wird. Beide werden gemeldet, damit Sie sie einsehen können, und keines von beiden senkt die Bewertung.

Warum wird bei der Überprüfung auch die Website unter http:// abgefragt?

Denn genau diese Anfrage stellt ein Besucher, wenn er die reine Domain eingibt. Die Antwort muss eine Weiterleitung zu https:// auf demselben Host sein. Sollte die erste Station ein anderer Host sein, sieht der Browser bei diesem Besuch den HSTS-Header dieses Hosts nicht, und die HSTS-Preload-Liste lehnt die Domain ab.

Werden die Cookies meiner Website gespeichert?

Nein. Die Prüfung liest von jedem Cookie nur den Namen und die Flags (Secure, HttpOnly, SameSite). Die Werte werden verworfen, bevor irgendetwas gespeichert oder angezeigt wird, und ein geteiltes Ergebnis enthält dieselben Namen und Flags, sonst nichts.

Was eine einzelne Seite bereits über einen Besucher weiß

Adresse, Netzwerk, Browser, Schriftarten, Zeitzone. Sehen Sie sich das Profil an, das Ihre eigene Website erstellen könnte, ohne danach zu fragen.

Was wir über Sie wissen →

Die Hälfte Ihres Datenverkehrs stammt nicht von Menschen

Vergewissern Sie sich, ob ein Crawler, der in Ihren Logs auftaucht, tatsächlich die Suchmaschine ist, als die er sich ausgibt, bevor Sie ihn blockieren.

Bot-Verifizierung →

Header schützen den Browser, nicht das Postfach

Eine Domain, die E-Mails versendet, benötigt ebenfalls SPF, DKIM und DMARC, und diese müssen miteinander übereinstimmen.

E-Mail-Sicherheitsprüfung →

Header verhindern keinen Login-Versuch

Brute-Force-Angriffe, Scanner und Spam kommen dennoch an. Sie werden bereits vor der Passwortprüfung abgewehrt.

ReportedIP Hive →