HTTP-Security-Header prüfen

Womit anfangen, wenn Sie anfangen

Die Header sind weder gleich wertvoll noch gleich riskant im Einsatz. In der Reihenfolge, die den meisten Schutz bei der geringsten Chance bietet, etwas kaputtzumachen:

Die letzte Zeile ist die wichtigste und die einzige, die echte Arbeit macht. Alles darüber ist ein Nachmittag.

HSTS und die eine unumkehrbare Entscheidung darin

Strict-Transport-Security weist einen Browser an, für diesen Host die nächsten max-age Sekunden HTTPS zu verwenden, komme was wolle. Damit schließt es eine schmale, aber reale Lücke: Wer example.com eintippt, sendet vor Ihrer Weiterleitung eine Klartextanfrage, und die lässt sich abfangen.

Strict-Transport-Security: max-age=31536000; includeSubDomains

includeSubDomains zählt mehr, als es aussieht. Ohne es kann eine über HTTP ausgelieferte Subdomain weiterhin Cookies für die übergeordnete Domain setzen. Mit ihm muss jede Subdomain ausschließlich HTTPS sprechen, sonst wird sie unerreichbar — prüfen Sie also, bevor Sie es hinzufügen.

Über die Direktive preload sollte man gründlich nachdenken. Sie trägt Ihre Domain in die mit Browsern ausgelieferten Preload-Listen ein, HTTPS wird also erzwungen, bevor überhaupt die erste Anfrage stattfindet. Sie ist zugleich faktisch unumkehrbar: Eine Entfernung erfordert einen Antrag bei den Listenpflegern und dann das Warten auf Browser-Releases, also Monate. Ausgezeichnet, wenn Sie sicher sind; schlecht, um es nebenbei zu setzen.

CSP: Der Nur-Melden-Modus ist nicht optional

Eine Content-Security-Policy ist der einzige Header hier, der eingeschleustes Skript am Laufen hindert, und der einzige, der Ihre Seite lahmlegen kann. Beides folgt aus derselben Eigenschaft: Sie schränkt ein, was geladen werden darf.

Setzen Sie sie im Nur-Melden-Modus mit einem Sammler ein und lassen Sie sie ein paar Wochen echten Verkehr laufen. Was Sie finden, ist nicht das, was das Lesen des Codes vermuten ließ: ein vergessener Schrifthost, ein Zahlungs-iframe und häufig ein Skript, das am CDN-Rand eingeschleust wird und in keiner Quelldatei auftaucht. Genau diese letzte Kategorie soll der Nur-Melden-Modus sichtbar machen.

Content-Security-Policy-Report-Only: default-src 'self';
  script-src 'self'; object-src 'none'; base-uri 'self';
  report-uri /csp-report

Zwei Dinge machen den Nutzen weitgehend zunichte. 'unsafe-inline' in script-src erlaubt exakt das eingeschleuste Inline-Skript, das die Richtlinie verhindern soll — Nonces oder Hashes sind der Ausweg. Und 'unsafe-eval' schaltet eval und Verwandtes wieder frei, was manche ältere Framework-Builds noch brauchen. Der Prüfer markiert beides als Schwächung statt als Fehlen, denn eine Richtlinie mit ihnen leistet immer noch Nützliches; nur eben nicht die Hauptaufgabe.

Header, deren Empfehlung abgelaufen ist

• `X-XSS-Protection` — steuerte einen Browserfilter, der aus allen großen Browsern entfernt wurde und sich seinerzeit selbst so manipulieren ließ, dass er Seiten zerstörte. Kein Header, den man 2026 setzt.
• `Expect-CT` — überholt. Certificate Transparency wird inzwischen bedingungslos durchgesetzt, der Header tut also nichts.
• `Feature-Policy` — umbenannt in Permissions-Policy, mit anderer Syntax. Nur der neue Name wird beachtet.
• `Public-Key-Pins` — aus den Browsern entfernt, und zu Recht. Ein Fehler darin legte Ihre Domain für die Dauer der Bindung lahm, ohne jede Möglichkeit zur Erholung.

Was dies nicht prüft

Eine Seite, eine Antwort. Es liest die Header der Endantwort nach dem Verfolgen von Weiterleitungen und hört dort auf. Es durchsucht die Seite nicht, führt kein JavaScript aus, testet Ihre TLS-Konfiguration nicht und prüft keine Cookie-Flags — und verschiedene Pfade derselben Seite können völlig unterschiedliche Header senden, die Startseite zu prüfen sagt Ihnen also etwas über die Startseite.

Für die TLS-Konfiguration im Besonderen ist Qualys SSL Labs das etablierte Werkzeug und gründlich. Für das Zertifikat selbst liest dieses hier, was ein Host tatsächlich vorlegt.