HTTP Strict Transport Security (HSTS) im Detail: HTTPS-Zwang

HTTP Strict Transport Security (HSTS) ist ein kritischer Sicherheits-Response-Header, der Webbrowser dazu zwingt, eine Website ausschliesslich über verschlüsselte HTTPS-Verbindungen aufzurufen. HSTS schützt Unternehmen und deren Nutzer vor Man-in-the-Middle-Angriffen, insbesondere vor dem sogenannten SSL-Stripping (Herabstufen einer HTTPS-Verbindung auf unverschlüsseltes HTTP), und unterbindet das Umgehen von SSL-Zertifikatswarnungen durch die Anwender.

HSTS ist einer der wichtigsten Security Header überhaupt, weil er eine grundlegende Schwachstelle des Webs schliesst: den unverschlüsselten ersten Verbindungsaufbau. Zusammen mit einer starken Content Security Policy bildet er das Fundament einer gehärteten Webanwendung.

Die Sicherheitslücke: Das Problem der HTTP-Weiterleitung

Die meisten Websites leiten HTTP-Anfragen per 301-Redirect auf HTTPS um:

• Ein Nutzer gibt example.com in die Adresszeile ein.
• Der Browser sendet standardmässig eine unverschlüsselte Anfrage an http://example.com.
• Der Server antwortet mit einer Weiterleitung auf https://example.com.

Diese erste unverschlüsselte HTTP-Anfrage ist die grösste Angriffsfläche. Ein Angreifer im selben Netzwerk (z. B. in einem ungesicherten Hotel-WLAN) kann diese Anfrage abfangen, sich als Server ausgeben und dem Nutzer weiterhin eine manipulierte HTTP-Version der Website präsentieren, während er im Hintergrund die Daten mitliest.

---

Wie HSTS funktioniert

HSTS schliesst diese Lücke, indem der Server dem Browser beim ersten sicheren Aufruf einen HSTS-Header mitsendet:

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

Die Parameter im Detail:

• max-age=31536000: Teilt dem Browser mit, dass er sich für die nächsten 31’536’000 Sekunden (exakt ein Jahr) merken muss, diese Website ausschliesslich über HTTPS aufzurufen.
• includeSubDomains: Wichtig für B2B-Projekte: Wendet den HTTPS-Zwang automatisch auf alle Subdomains (z. B. api.example.com, mail.example.com) an.
• preload: Autorisiert die Aufnahme der Domain in die offizielle HSTS-Preload-Liste.

---

Die HSTS-Preload-Liste: Der ultimative Schutz

Selbst mit HSTS ist der allererste Aufruf der Website auf einem neuen Gerät oder nach dem Löschen des Browser-Verlaufs ungeschützt (da der Browser den HSTS-Header noch nie gesehen hat).

Um dieses „First-Visit-Problem“ zu lösen, pflegt Google eine HSTS-Preload-Liste, die direkt in den Quellcode aller grossen Browser (Chrome, Firefox, Safari, Edge) einkompiliert wird.

• Sobald Sie Ihre Domain auf der Plattform hstspreload.org registrieren, weiss jeder Browser weltweit bereits vor dem allerersten Seitenaufruf, dass Ihre Domain ausschliesslich über HTTPS geladen werden darf.
• Ein unverschlüsselter HTTP-Verbindungsaufbau wird auf Netzwerkebene des Browsers unmöglich gemacht.

---

Die drei Stufen der HSTS-Einführung

HSTS sollte man – ähnlich wie eine DMARC-Policy – schrittweise schärfen, um sich nicht selbst auszusperren:

Stufe	Header	Zweck	Dauer
1. Testen	max-age=300	Kurze Laufzeit, Fehler bleiben korrigierbar	wenige Tage
2. Etablieren	max-age=31536000; includeSubDomains	Voller HTTPS-Zwang inkl. Subdomains	mehrere Wochen
3. Preload	max-age=31536000; includeSubDomains; preload	Aufnahme in die Browser-Preload-Liste	dauerhaft

Erst wenn alle Subdomains nachweislich über gültige Zertifikate verfügen, sollte Stufe 3 erfolgen.

---

Typische HSTS-Fehlkonfigurationen

Fehler	Folge
includeSubDomains bei HTTP-only-Subdomain	Subdomain wird unerreichbar
Zu kurzer max-age	Schutz läuft schnell ab, First-Visit-Lücke bleibt
preload ohne erfüllte Voraussetzungen	Antrag wird abgelehnt, kein Schutz
HSTS auf reiner HTTP-Seite gesendet	Header wird ignoriert (nur über HTTPS gültig)

Ein häufiger Praxisfehler: Eine Domain wird vorschnell in die Preload-Liste eingetragen, obwohl ein Altsystem unter einer Subdomain nur HTTP spricht. Da das Entfernen aus der Liste Monate dauern kann, ist sorgfältige Vorbereitung entscheidend.

---

HSTS im Zusammenspiel mit anderen Massnahmen

HSTS wirkt nur auf den Transportweg. Für eine umfassend abgesicherte Anwendung gehören weitere Bausteine dazu:

• Content Security Policy: Schutz vor Cross-Site-Scripting.
• X-Frame-Options: Schutz vor Clickjacking.
• Referrer-Policy: Kontrolle über weitergegebene Herkunftsinformationen.

Eine vollständige Übersicht bietet die Security-Header-Checkliste.

[!CAUTION] Der Eintrag in die Preload-Liste ist dauerhaft und schwer rückgängig zu machen. Stellen Sie sicher, dass alle Ihre Subdomains (auch Testumgebungen) über ein gültiges SSL-Zertifikat verfügen, bevor Sie die Registrierung durchführen. Prüfen Sie Ihre HSTS-Konfiguration mit dem Security Header Check auf balou.tools.