Was ist HSTS (HTTP Strict Transport Security)?

HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus, der Browser anweist, ausschliesslich ueber 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 fuer 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, loest aber ein echtes und gefaehrliches 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 oeffnet seinen Laptop in einem Cafe und tippt deineseite.de in den Browser. Ohne HSTS sendet der Browser zuerst eine unverschluesselte HTTP-Anfrage an deinen Server. Dein Server antwortet dann mit einem 301-Redirect auf https://deineseite.de. Diese erste HTTP-Anfrage ist jedoch komplett unverschluesselt. Sie wird als Klartext ueber das WLAN-Netzwerk des Cafes uebertragen.

Ein Angreifer im selben Netzwerk kann diese erste unverschluesselte Anfrage mit einer Technik namens SSL-Stripping abfangen. Der Angreifer agiert als Proxy: Er haelt 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 oeffentlich verfuegbar, und SSL-Stripping bleibt einer der praktikabelsten Angriffe in oeffentlichen WLAN-Netzwerken. HSTS wurde genau entwickelt, um diese Luecke zu schliessen.

Wie HSTS deine WordPress-Seite schuetzt

Wenn dein Server den folgenden Response-Header sendet:

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

Speichert der Browser diese Anweisung intern. Fuer die naechsten 31.536.000 Sekunden (ein Jahr) wird er niemals eine HTTP-Verbindung zu deiner Domain versuchen. Wenn irgendetwas versucht, eine Ressource ueber HTTP zu laden, schreibt der Browser die URL lokal auf HTTPS um, bevor die Anfrage das Geraet ueberhaupt verlaesst. Es gibt keine unverschluesselte Anfrage, die ein Angreifer abfangen koennte.

Dieser Schutz arbeitet auf Browser-Ebene, und das ist der entscheidende Vorteil. Kein Redirect wird benoetigt. Keine unverschluesselte Anfrage wird jemals gesendet. Der Browser weigert sich schlicht, HTTP fuer 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. Gaengige Werte sind 86400 (1 Tag, nuetzlich fuer erste Tests), 2592000 (30 Tage, ein vernuenftiger Startpunkt) und 31536000 (1 Jahr, der empfohlene Produktionswert). Setzt du diesen Wert auf Null, hebt der Browser die HSTS-Erzwingung fuer 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 unterstuetzt, wird sie unerreichbar, sobald dies aktiv ist.
• preload: Ein Signal, dass du deine Domain in Browser-Preload-Listen aufnehmen lassen moechtest. Mehr dazu weiter unten.

Das Erstbesuch-Problem und HSTS-Preload-Listen

HSTS hat eine grundlegende Einschraenkung: 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 anfaellig fuer Abfangen. Das wird als "Erstbesuch-Problem" oder "Bootstrap-Problem" bezeichnet.

Die HSTS-Preload-Liste loest 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, muessen alle folgenden Voraussetzungen erfuellt sein:

• Ein gueltiges 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 einschliessen
• Die preload-Direktive einschliessen
• Alle Subdomains muessen HTTPS unterstuetzen

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 zuverlaessig funktioniert, bevor du die Domain einreichst.

Gaengige 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 waehrend der ersten Tests. Wenn etwas schiefgeht, sind Besucher nur fuer fuenf Minuten auf HTTPS festgelegt.
• max-age=86400 (1 Tag): Ein guter naechster Schritt, sobald du bestaetigt 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 fuer die Preload-Liste.

HSTS auf einer WordPress-Seite einrichten

WordPress sendet den HSTS-Header standardmaessig nicht. Du hast mehrere Moeglichkeiten, ihn hinzuzufuegen:

Der zuverlaessigste Ansatz ist, den Header auf Server-Ebene hinzuzufuegen. In Apache fuege dies in deine .htaccess-Datei oder Virtual-Host-Konfiguration ein:

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

Fuer Nginx fuege 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 (haeufig bei Shared Hosting), kannst du den Header ueber PHP in der functions.php deines Themes oder ueber 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, einschliesslich statischer Dateien und Fehlerseiten, nicht nur auf PHP-generierte Seiten.

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

Haeufige Stolperfallen bei HSTS mit WordPress

Bevor du HSTS aktivierst, pruefe einige Dinge:

• Mixed Content: Stelle sicher, dass alle Ressourcen (Bilder, Skripte, Stylesheets, Schriftarten) ueber 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 gueltiges 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 ueberschreiben koennen.

Was InspectWP prueft

InspectWP analysiert, ob deine WordPress-Seite den Strict-Transport-Security Response-Header sendet. Der Report bewertet den max-age-Wert, prueft 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 fuer jede WordPress-Seite empfohlen, die ueber HTTPS laeuft, und das sollten heutzutage alle sein.