HSTS
HSTS (HTTP Strict Transport Security) ist eine Server-Anweisung per HTTP-Header, die den Browser dazu verpflichtet, eine Domain für einen festgelegten Zeitraum ausschließlich über HTTPS aufzurufen – auch wenn der Nutzer eine HTTP-Adresse eingibt.
HSTS schließt die letzte verbleibende Sicherheits-Lücke einer HTTPS-Auslieferung: den unverschlüsselten ersten Zugriff vor der HTTPS-Umleitung. Es ist heute De-facto-Standard für Websites mit erhöhten Schutz-Anforderungen.
In einfachen Worten
Auch wenn eine Website vollständig auf HTTPS umgestellt ist, kann ein Angreifer im selben Netzwerk versuchen, die allererste Anfrage abzufangen und auf eine gefälschte HTTP-Variante umzuleiten, bevor die Weiterleitung auf HTTPS greift. HSTS schließt genau diese Lücke: Der Server sendet einen Header mit dem Hinweis „Rufe meine Domain in den nächsten Monaten ausschließlich über HTTPS auf, ohne Ausnahme". Der Browser merkt sich diese Anweisung für die Dauer der angegebenen max-age-Zeit und ruft die Domain anschließend selbst dann verschlüsselt auf, wenn jemand eine HTTP-Adresse eingibt. Optional lässt sich die Domain in eine browserweite Preload-Liste eintragen, sodass schon der allererste Zugriff verschlüsselt erfolgt – ohne dass der Browser die Anweisung jemals zuvor selbst empfangen haben muss.
Wozu brauche ich das?
Empfohlen für jede Website, die produktiv unter HTTPS läuft. Faktisch verpflichtend für alle Anwendungen, die sensible Daten verarbeiten (Anmeldungen, Bezahl-Vorgänge, Gesundheits-Daten). Auch für Online-Shops und Buchungs-Systeme ein einfacher Sicherheits-Gewinn ohne Performance-Nachteil. Voraussetzung ist immer eine stabil laufende HTTPS-Auslieferung auf Basis von SSL/TLS – sonst sperrt der Browser den Zugriff über die HSTS-Laufzeit selbst aus.
Beispiel aus der Praxis
Eine typische Konstellation: Eine Anwaltskanzlei betreibt ein Mandanten-Portal, in das sich Mandanten auch aus offenen Hotel- oder Café-Netzen anmelden. Klassischer Angriffs-Vektor in solchen Netzen: Der Angreifer fängt die erste Anfrage ab und leitet sie auf eine gefälschte HTTP-Variante um, um die Anmelde-Daten abzugreifen. HSTS mit einer Laufzeit von zwölf Monaten schließt diese Lücke: Der Browser der Mandantin oder des Mandanten ignoriert nach dem ersten erfolgreichen HTTPS-Aufruf jede HTTP-Umleitung der Domain und versucht direkt HTTPS. Der Angriffs-Versuch läuft ins Leere – ohne dass die Mandantin oder der Mandant etwas tun oder bemerken müssen.
Wirtschaftlicher Nutzen
HSTS kostet weder Lizenz noch wiederkehrende Gebühren – nur einmalig wenige Minuten Konfiguration im Webserver. Der Gewinn ist die belastbare Schließung der First-Visit-Lücke, die jede HTTPS-Website ansonsten offen lässt. Für Branchen mit erhöhten Schutz-Anforderungen (Recht, Gesundheit, Finanzen) ist HSTS – als einer der wichtigsten Security-Header – heute De-facto-Standard. Wichtig: HTTPS muss vor der Aktivierung stabil und vollständig laufen, sonst kann sich der Browser für die Dauer der HSTS-Laufzeit selbst aussperren – Rückkehr zu HTTP ist innerhalb der Laufzeit nicht möglich.
Typische Fehler
- HSTS aktiviert, bevor HTTPS auf allen Pfaden sauber läuft – Besucher können einzelne Bereiche plötzlich nicht mehr erreichen, ohne dass eine Korrektur möglich ist.
- Zu lange max-age-Werte direkt am Anfang gesetzt – Konfigurations-Fehler werden monatelang konserviert.
- Subdomains über die Direktive includeSubDomains eingeschlossen, ohne dass dort überall HTTPS sauber läuft – Teile der Sub-Strecke werden unerreichbar.
- Ohne Notfall-Plan in die browserweite Preload-Liste eintragen lassen – ein Auswurf aus dieser Liste dauert mehrere Wochen.
- Vor Server-Umzügen die HSTS-Konfiguration nicht geprüft – nach dem Umzug fehlen die Header und die Schutzwirkung entfällt schleichend.
Worauf achten?
- Mit einer kurzen max-age-Laufzeit (etwa zehn Minuten) starten und schrittweise auf sechs bis zwölf Monate erhöhen, sobald die Konfiguration stabil läuft.
- includeSubDomains erst aktivieren, wenn alle Subdomains zuverlässig über HTTPS erreichbar sind.
- Eintragung in die Preload-Liste erst nach mehreren Wochen Stabil-Betrieb beantragen – ein Eintrag ist nicht trivial rückgängig zu machen.
- Vor jedem Server-Umzug die HSTS-Konfiguration explizit prüfen, sodass die Header auch auf dem neuen System gesetzt werden.
- Im Monitoring eine fortlaufende Prüfung des HSTS-Headers integrieren – ein unbemerkter Ausfall der Konfiguration bleibt sonst lange unentdeckt.
Häufig gestellte Fragen
Wofür steht HSTS?
HTTP Strict Transport Security – eine Server-Anweisung per HTTP-Header, die den Browser dazu verpflichtet, eine Domain für einen festgelegten Zeitraum ausschließlich über HTTPS aufzurufen. Sie schließt die unverschlüsselte First-Visit-Lücke jeder klassischen HTTPS-Umstellung.
Welche max-age-Laufzeit ist sinnvoll?
Zum Start eine kurze Laufzeit von wenigen Minuten, schrittweise erhöht auf sechs bis zwölf Monate, sobald die HTTPS-Auslieferung stabil läuft. Die kurze Anfangs-Laufzeit erlaubt eine schnelle Rückkehr im Fehler-Fall, die spätere lange Laufzeit liefert die volle Schutz-Wirkung.
Was bedeutet includeSubDomains?
Eine optionale Direktive, die die HSTS-Anweisung auf alle Subdomains der eigenen Domain erweitert. Sinnvoll, wenn dort durchgängig HTTPS läuft – sonst werden einzelne Sub-Pfade unerreichbar.
Was ist die HSTS-Preload-Liste?
Eine browserweite Liste von Domains, die selbst beim allerersten Aufruf nur über HTTPS angesprochen werden. Sie ist die maximal harte Form von HSTS – ein Auswurf dauert mehrere Wochen, weshalb der Eintrag erst nach mehreren Wochen Stabil-Betrieb beantragt werden sollte.
Was passiert, wenn HTTPS später ausfällt?
Innerhalb der HSTS-Laufzeit ist kein Zugriff über HTTP mehr möglich – der Browser erzwingt die HTTPS-Verbindung. Fällt das Zertifikat aus oder läuft der Server nicht mehr unter HTTPS, ist die Domain für die Dauer der gespeicherten Laufzeit unerreichbar.