Was ist HSTS (HTTP Strict Transport Security)?

HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus, der Browser anweist, ausschließlich über HTTPS mit deiner Website zu kommunizieren. Sobald ein Browser den HSTS-Header von deinem Server empfangen hat, wandelt er automatisch alle HTTP-Anfragen in HTTPS um, und zwar für die im Header angegebene Dauer. Das gilt selbst dann, wenn der Nutzer bewusst http:// in die Adressleiste eingibt oder auf einen alten HTTP-Link klickt.

Das klingt vielleicht nach einer kleinen Komfortfunktion, löst aber ein echtes und gefährliches Problem. Schauen wir uns genau an, warum HSTS existiert, wie es in der Praxis funktioniert und was du als WordPress-Betreiber wissen musst.

Wie SSL-Stripping-Angriffe ohne HSTS funktionieren

Stell dir vor, ein Besucher öffnet seinen Laptop in einem Café und tippt deineseite.de in den Browser. Ohne HSTS sendet der Browser zuerst eine unverschlüsselte HTTP-Anfrage an deinen Server. Dein Server antwortet dann mit einem 301-Redirect auf https://deineseite.de. Diese erste HTTP-Anfrage ist jedoch komplett unverschlüsselt. Sie wird als Klartext über das WLAN-Netzwerk des Cafés übertragen.

Ein Angreifer im selben Netzwerk kann diese erste unverschlüsselte Anfrage mit einer Technik namens SSL-Stripping abfangen. Der Angreifer agiert als Proxy: Er hält eine HTTPS-Verbindung zu deinem echten Server aufrecht, liefert dem Opfer aber eine reine HTTP-Version der Seite. Aus Sicht des Besuchers sieht die Seite normal aus (die meisten Menschen achten nicht auf das Schloss-Symbol). In der Zwischenzeit kann der Angreifer alles mitlesen: Login-Daten, Formulareingaben, Session-Cookies, Kreditkartendaten.

Das ist kein theoretischer Angriff. Tools wie sslstrip sind seit 2009 öffentlich verfügbar, und SSL-Stripping bleibt einer der praktikabelsten Angriffe in öffentlichen WLAN-Netzwerken. HSTS wurde genau entwickelt, um diese Lücke zu schließen.

Wie HSTS deine WordPress-Seite schützt

Wenn dein Server den folgenden Response-Header sendet:

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

speichert der Browser diese Anweisung intern. Für die nächsten 31.536.000 Sekunden (ein Jahr) wird er niemals eine HTTP-Verbindung zu deiner Domain versuchen. Wenn irgendetwas versucht, eine Ressource über HTTP zu laden, schreibt der Browser die URL lokal auf HTTPS um, bevor die Anfrage das Gerät überhaupt verlässt. Es gibt keine unverschlüsselte Anfrage, die ein Angreifer abfangen könnte.

Dieser Schutz arbeitet auf Browser-Ebene, und das ist der entscheidende Vorteil. Kein Redirect wird benötigt. Keine unverschlüsselte Anfrage wird jemals gesendet. Der Browser weigert sich schlicht, HTTP für deine Domain zu verwenden.

HSTS-Header-Direktiven im Detail

Der HSTS-Header akzeptiert drei Direktiven, und jede hat einen bestimmten Zweck:

• max-age: Die Zeit in Sekunden, die der Browser sich merken soll, HTTPS zu erzwingen. Gängige Werte sind 86400 (1 Tag, nützlich für erste Tests), 2592000 (30 Tage, ein vernünftiger Startpunkt) und 31536000 (1 Jahr, der empfohlene Produktionswert). Setzt du diesen Wert auf Null, hebt der Browser die HSTS-Erzwingung für deine Domain sofort auf.
• includeSubDomains: Erweitert die HSTS-Richtlinie auf alle Subdomains. Das bedeutet, cdn.deineseite.de, mail.deineseite.de und jede andere Subdomain wird ebenfalls auf HTTPS gezwungen. Vorsicht bei dieser Direktive: Wenn eine Subdomain kein HTTPS unterstützt, wird sie unerreichbar, sobald dies aktiv ist.
• preload: Ein Signal, dass du deine Domain in Browser-Preload-Listen aufnehmen lassen möchtest. Mehr dazu weiter unten.

Das Erstbesuch-Problem und HSTS-Preload-Listen

HSTS hat eine grundlegende Einschränkung: Der Browser muss den Header mindestens einmal empfangen haben, bevor er irgendetwas erzwingen kann. Beim allerersten Besuch, bevor der Browser deinen HSTS-Header jemals gesehen hat, ist die initiale HTTP-Anfrage immer noch anfällig für Abfangen. Das wird als „Erstbesuch-Problem" oder „Bootstrap-Problem" bezeichnet.

Die HSTS-Preload-Liste löst dieses Problem. Es handelt sich um eine Liste von Domains, die direkt in den Browser eingebaut ist (Chrome, Firefox, Safari und Edge nutzen alle dieselbe Liste). Wenn deine Domain auf der Preload-Liste steht, erzwingt der Browser HTTPS ab der allerersten Verbindung, selbst wenn der Nutzer deine Seite noch nie besucht hat.

Um deine Domain auf die Preload-Liste zu bekommen, müssen alle folgenden Voraussetzungen erfüllt sein:

• Ein gültiges HTTPS-Zertifikat auf deiner Root-Domain bereitstellen
• Allen HTTP-Traffic auf HTTPS auf demselben Host umleiten
• Den HSTS-Header auf der Root-Domain mit max-age von mindestens 31536000 (ein Jahr) senden
• Die includeSubDomains-Direktive einschließen
• Die preload-Direktive einschließen
• Alle Subdomains müssen HTTPS unterstützen

Du kannst deine Domain unter hstspreload.org einreichen. Bedenke, dass die Aufnahme Wochen oder Monate dauern kann (sie wird mit Browser-Updates ausgeliefert), und die Entfernung ebenso langsam ist. Stelle sicher, dass dein HTTPS-Setup zuverlässig funktioniert, bevor du die Domain einreichst.

Gängige max-age-Werte und empfohlene Rollout-Strategie

Es ist verlockend, direkt auf ein Jahr max-age zu gehen, aber ein schrittweiser Rollout ist sicherer, besonders bei Seiten mit mehreren Subdomains oder komplexen Setups:

• max-age=300 (5 Minuten): Verwende diesen Wert während der ersten Tests. Wenn etwas schiefgeht, sind Besucher nur für fünf Minuten auf HTTPS festgelegt.
• max-age=86400 (1 Tag): Ein guter nächster Schritt, sobald du bestätigt hast, dass HTTPS korrekt funktioniert.
• max-age=2592000 (30 Tage): Wechsle hierhin nach ein bis zwei Wochen stabilem Betrieb.
• max-age=31536000 (1 Jahr): Der empfohlene Produktionswert. Dies ist auch das Minimum für die Preload-Liste.

HSTS auf einer WordPress-Seite einrichten

WordPress sendet den HSTS-Header standardmäßig nicht. Du hast mehrere Möglichkeiten, ihn hinzuzufügen:

Der zuverlässigste Ansatz ist, den Header auf Server-Ebene hinzuzufügen. In Apache füge dies in deine .htaccess-Datei oder Virtual-Host-Konfiguration ein:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Für Nginx füge dies in deinen server-Block ein:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Wenn du keinen Zugang zur Server-Konfiguration hast (häufig bei Shared Hosting), kannst du den Header über PHP in der functions.php deines Themes oder über ein Must-Use-Plugin setzen:

add_action('send_headers', function() {
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
});

Der Server-Level-Ansatz ist vorzuziehen, da er auf alle Antworten angewendet wird, einschließlich statischer Dateien und Fehlerseiten, nicht nur auf PHP-generierte Seiten.

Mehrere WordPress-Sicherheitsplugins bieten ebenfalls eine HSTS-Konfiguration über ihre Einstellungen an, was praktisch sein kann, wenn du einen GUI-basierten Ansatz bevorzugst.

Häufige Stolperfallen bei HSTS mit WordPress

Bevor du HSTS aktivierst, prüfe einige Dinge:

• Mixed Content: Stelle sicher, dass alle Ressourcen (Bilder, Skripte, Stylesheets, Schriftarten) über HTTPS geladen werden. HSTS erzwingt die Hauptverbindung auf HTTPS, aber wenn deine Inhalte noch HTTP-URLs referenzieren, blockieren Browser diese Ressourcen.
• SSL-Zertifikatserneuerung: Sobald HSTS aktiv ist, macht ein abgelaufenes Zertifikat deine Seite komplett unerreichbar (statt eine umgehbare Warnung anzuzeigen). Richte automatische Zertifikatserneuerung mit Let's Encrypt oder deinem Zertifikatsanbieter ein.
• Subdomain-Bereitschaft: Wenn du includeSubDomains verwendest, braucht jede einzelne Subdomain ein gültiges HTTPS-Zertifikat. Eine Staging-Subdomain auf HTTP funktioniert dann nicht mehr.
• CDN-Konfiguration: Wenn du ein CDN wie Cloudflare verwendest, stelle sicher, dass HSTS konsistent konfiguriert ist. Cloudflare bietet eigene HSTS-Einstellungen, die deine Server-Header überschreiben können.

Was InspectWP prüft

InspectWP analysiert, ob deine WordPress-Seite den Strict-Transport-Security Response-Header sendet. Der Report bewertet den max-age-Wert, prüft auf die includeSubDomains-Direktive und markiert den Header als fehlend, wenn er nicht vorhanden ist. Ein korrekter HSTS-Header mit einem langen max-age-Wert (mindestens 6 Monate oder ein Jahr) und der includeSubDomains-Direktive wird für jede WordPress-Seite empfohlen, die über HTTPS läuft, und das sollten heutzutage alle sein.