HSTS (HTTP Strict Transport Security) ist ein HTTP-Antwort-Header, mit dem ein Server dem Browser vorschreibt, eine Domain für einen festgelegten Zeitraum ausschließlich über HTTPS anzusprechen. Nach dem ersten Besuch über eine verschlüsselte Verbindung merkt sich der Browser die Regel und schreibt jeden späteren http://-Aufruf lokal auf https:// um, bevor ein einziges Byte unverschlüsselt das Gerät verlässt. Definiert ist der Mechanismus in RFC 6797 aus dem Jahr 2012. HSTS gehört zu den Security Headern, die sich mit einer Zeile Webserver-Konfiguration setzen lassen und trotzdem auf einem Großteil der Websites fehlen.
Wie HSTS funktioniert
Ohne HSTS läuft ein typischer Erstaufruf so ab: Der Nutzer tippt deinshop.de in die Adresszeile, der Browser ergänzt http://, schickt einen unverschlüsselten Request, und der Server antwortet mit einer 301-Umleitung auf die HTTPS-Adresse. Erst der zweite Request ist verschlüsselt. Dieser eine offene Request ist das Problem. In einem öffentlichen WLAN kann jeder, der den Verkehr mitliest, die Antwort fälschen, Session-Cookies abgreifen oder den Nutzer auf eine Kopie der Seite lenken. Die Angriffsklasse heißt SSL-Stripping; das Werkzeug dazu, sslstrip, wurde bereits 2009 öffentlich vorgestellt.
HSTS schließt dieses Fenster. Der Server sendet auf der verschlüsselten Verbindung den Header:
Strict-Transport-Security: max-age=31536000; includeSubDomainsDer Browser speichert daraufhin einen Eintrag für die Domain. Solange die in max-age angegebene Zeit in Sekunden nicht abgelaufen ist, wird jeder Aufruf dieser Domain intern auf HTTPS umgeschrieben. Das gilt für getippte Adressen, für Links aus Newslettern und Preisvergleichen, für Bookmarks und für Ressourcen, die eine andere Seite einbettet. Zusätzlich verhält sich der Browser bei Zertifikatsfehlern anders: Normalerweise darf ein Nutzer eine Warnung wegen eines abgelaufenen oder falschen Zertifikats wegklicken. Bei einer HSTS-Domain ist das nicht mehr möglich. Der Browser bricht ab, ohne eine Ausnahme anzubieten.
Drei Eigenschaften des Mechanismus bestimmen den Umgang damit in der Praxis. Erstens wertet der Browser den Header nur aus, wenn er über HTTPS mit gültigem Zertifikat ankommt; ein HSTS-Header auf einer HTTP-Antwort wird ignoriert, die Umleitung auf HTTPS muss also zuerst stehen. Zweitens wird die Laufzeit bei jeder weiteren Antwort mit Header neu gesetzt, ein regelmäßiger Besucher verliert den Eintrag deshalb nie. Drittens verarbeitet der Browser laut RFC 6797 nur den ersten HSTS-Header einer Antwort. Setzt die Anwendung einen Wert und der Webserver einen zweiten, zählt der, der zuerst in der Antwort steht.
Die drei Direktiven
| Direktive | Wirkung | Empfehlung |
|---|---|---|
max-age | Gültigkeitsdauer der Regel in Sekunden, gerechnet ab der letzten Antwort mit Header | OWASP: 63072000 (zwei Jahre); Preload-Liste: mindestens 31536000 (ein Jahr) |
includeSubDomains | Dehnt die Regel auf alle Subdomains aus, auch auf solche, die der Browser nie besucht hat | Setzen, sobald wirklich jede Subdomain HTTPS spricht |
preload | Signalisiert die Zustimmung zur Aufnahme in die fest in Browser eingebaute Liste | Erst nach mehreren Wochen stabilem Zwei-Jahres-Wert |
max-age ist die einzige Pflichtangabe. Ein Wert von 0 ist ebenfalls gültig und löscht den gespeicherten Eintrag im Browser; das ist der einzige Rückweg, wenn eine zu weit gefasste Regel Systeme aussperrt. includeSubDomains ist die Direktive mit dem größten Fehlerpotenzial, weil sie Systeme betrifft, die niemand im Blick hat: das Intranet unter einer Subdomain, ein Staging-System mit selbst signiertem Zertifikat, ein alter Statistik-Server. Nach dem ersten Besuch der Hauptdomain ist all das für den betroffenen Browser unerreichbar, und zwar für die volle Laufzeit.
Preload: HSTS vor dem ersten Besuch
HSTS arbeitet nach dem Prinzip „Trust on first use". Der allererste Aufruf einer Domain bleibt ungeschützt, weil der Browser die Regel noch nicht kennt. Die Preload-Liste schließt diese Lücke. Sie ist eine in den Quellcode von Chromium eingebettete Liste von Domains, für die der Browser HSTS auch ohne vorherigen Besuch anwendet; Firefox, Safari und Edge übernehmen diese Liste. Betrieben wird sie über hstspreload.org.
Die Aufnahmebedingungen sind das beste reale Beispiel dafür, wie eine vollständige HSTS-Konfiguration aussieht. hstspreload.org verlangt:
- ein gültiges Zertifikat für die Domain,
- eine Umleitung von HTTP auf HTTPS auf demselben Host, falls der Server auf Port 80 überhaupt antwortet,
- HTTPS auf allen Subdomains, ausdrücklich einschließlich der
www-Subdomain, sofern dafür ein DNS-Eintrag existiert, - einen HSTS-Header auf der Basis-Domain mit
max-agevon mindestens 31536000 Sekunden, mitincludeSubDomainsund mitpreload.
Die Betreiber der Liste warnen auf derselben Seite deutlich: Die Aufnahme ist für die Praxis dauerhaft. Eine Domain lässt sich zwar wieder entfernen, aber die Entfernung erreicht die Nutzer erst mit dem nächsten Browser-Release und braucht Monate, bis sie flächendeckend angekommen ist. Wer eine Subdomain hat, die aus technischen Gründen HTTP sprechen muss, meldet die Domain nicht an. Punkt.
Für eine Anwendung, die heute noch keinen HSTS-Header sendet, empfiehlt hstspreload.org deshalb einen Stufenplan: Erst alle Subdomains auf HTTPS bringen und die Umleitung prüfen. Dann max-age=300, also fünf Minuten, setzen und beobachten. Dann eine Woche (604800), dann einen Monat (2592000), dann zwei Jahre (63072000). Zwischen den Stufen die volle Laufzeit abwarten, damit ein Fehler nicht für ein Jahr in Browsern festsitzt. Erst wenn der Zwei-Jahres-Wert mit includeSubDomains mehrere Wochen ohne Vorfall läuft, kommt preload dazu und die Domain wird eingereicht.
Warum HSTS für Onlineshops zählt
Ein Shop hat zwei Dinge, die ein Angreifer im offenen WLAN haben will: die Session des eingeloggten Kunden und die Zahlungsdaten im Checkout. Beides wandert über Cookies und Formulare. Ohne HSTS reicht ein einziger http://-Link, etwa aus einem alten Newsletter oder einem Preisvergleichsportal, damit der erste Request unverschlüsselt rausgeht. Mit HSTS ist das nach dem ersten HTTPS-Besuch ausgeschlossen. Das Verhältnis aus Aufwand und Wirkung ist bei keinem anderen Security Header so gut. Laut HTTP Archive Web Almanac 2025 tragen trotzdem nur 36 Prozent der mobil gecrawlten Seiten einen HSTS-Header.
Bei einem Plattformwechsel gehört HSTS neben die 301-Redirects auf die Checkliste. Die alten http://-URLs aus Suchmaschinen, Verlinkungen und Kampagnen bleiben jahrelang im Umlauf; HSTS sorgt dafür, dass sie bei wiederkehrenden Besuchern gar nicht erst unverschlüsselt angefragt werden. Für die Abwicklung von Zahlungen kommt ein zweiter Aspekt hinzu: Ein Payment Service Provider bindet seine Skripte und Frames ausschließlich über HTTPS ein, und PCI-DSS-Audits fragen die Transportverschlüsselung aller Seiten ab, auf denen Zahlungsdaten eingegeben werden. HSTS ist dafür kein Ersatz, aber der Nachweis, dass ein Downgrade ausgeschlossen ist.
HSTS in Shopware 6
Shopware 6 setzt den Header im Core selbst. Der CoreSubscriber hängt an jede erfolgreiche Antwort, die Shopware als HTTPS-Request erkennt, den Wert max-age=31536000; includeSubDomains an, zusammen mit X-Frame-Options: deny, X-Content-Type-Options: nosniff und Referrer-Policy: strict-origin-when-cross-origin. Zwei Konsequenzen folgen daraus.
Erstens ist der Stufenplan für die HTML-Seiten eines Shopware-Shops hinfällig: Ein Jahr mit includeSubDomains ist dort bereits live, und weil der Browser nur den ersten HSTS-Header auswertet, ändert ein kürzerer Wert am Webserver daran nichts. Subdomains ohne HTTPS sperren bei Shopware-Shops heute schon jeden Besucher aus, der die Hauptdomain einmal aufgerufen hat. Auch der Rückbau über max-age=0 am Webserver greift nicht, weil der Core-Header zuerst in der Antwort steht. Dauerhaft hilft nur, die betroffene Subdomain auf HTTPS zu bringen.
Zweitens gilt der Core-Header nur für Antworten, die durch PHP laufen. Theme-Dateien, Medien und Thumbnails liefert der Webserver direkt aus, und auf diesen Antworten fehlt alles, was der Core setzt. Der Webserver sollte deshalb denselben oder einen längeren Wert tragen. Dazu kommt die HTTPS-Erkennung: Hinter einem Load Balancer oder Cloudflare, der TLS terminiert und intern HTTP spricht, erkennt Shopware den Request nur dann als sicher, wenn TRUSTED_PROXIES korrekt gesetzt ist. Ist es das nicht, lässt der Core HSTS weg, ohne dass es im Browser auffällt. Ein Scan mit dem HTTP Observatory von MDN oder ein curl -I auf Startseite, eine CSS-Datei und eine 404-Seite zeigt, wo der Header fehlt.
Typische Fehler und Abgrenzung
Der häufigste Fehler ist, HSTS mit der HTTP-zu-HTTPS-Umleitung zu verwechseln. Die Umleitung passiert, nachdem der Browser den unverschlüsselten Request abgeschickt hat. HSTS verhindert, dass dieser Request überhaupt abgeschickt wird. Beides zusammen ist nötig: die Umleitung für den Erstbesuch, HSTS für alle Besuche danach.
Der zweite Fehler ist ein zu früh gesetztes includeSubDomains. Die Direktive wirkt auf Subdomains, die der Browser nie gesehen hat, und sie wirkt für die volle Laufzeit. Wer sie setzt, braucht vorher eine vollständige Liste aller DNS-Einträge unter der Domain und die Gewissheit, dass jeder davon HTTPS mit gültigem Zertifikat spricht. Der dritte Fehler ist ein zu früher Preload-Antrag, weil er sich nicht kurzfristig zurücknehmen lässt.
Abzugrenzen ist HSTS von zwei verwandten Konzepten. HTTP Public Key Pinning (HPKP) band eine Domain zusätzlich an bestimmte Zertifikatsschlüssel; Chrome hat den Header 2019 und Firefox 2020 wegen des Aussperr-Risikos entfernt, Safari hat ihn nie unterstützt. Und die Content Security Policy kennt mit upgrade-insecure-requests eine Direktive, die eingebettete HTTP-Ressourcen auf HTTPS hochstuft; sie ergänzt HSTS für den Fall von Mixed Content, ersetzt es aber nicht, weil sie nur innerhalb einer bereits geladenen Seite wirkt. Gegen eingeschleuste Skripte, also Cross-Site-Scripting, hilft HSTS gar nicht; dafür ist die CSP zuständig.
Häufige Fragen
Reicht eine 301-Umleitung auf HTTPS nicht aus?
Nein. Die Umleitung greift erst, nachdem der unverschlüsselte Request den Browser verlassen hat. HSTS verhindert genau diesen Request bei jedem Besuch nach dem ersten.
Wie entferne ich HSTS wieder, wenn ich ein System ausgesperrt habe?
Den Header auf max-age=0 setzen und die Hauptdomain einmal im betroffenen Browser aufrufen; damit löscht der Browser den Eintrag. Das wirkt nur pro Browser, nur wenn die Domain nicht in der Preload-Liste steht und bei Shopware-Shops nicht über den Webserver, weil der Core-Header zuerst steht.
Muss ich HSTS auch setzen, wenn Shopware es schon sendet?
Ja, am Webserver mit demselben oder einem längeren Wert. Der Core-Header liegt nur auf Antworten, die durch PHP laufen; statische Dateien und Fehlerseiten bekommen ihn nicht. Hinter einem TLS-terminierenden Proxy fehlt er ganz, wenn TRUSTED_PROXIES nicht stimmt.
Welchen max-age-Wert soll ich nehmen?
Für eine Anwendung, die noch keinen Header sendet: mit 300 Sekunden starten und über eine Woche und einen Monat auf zwei Jahre hochgehen. Für Shopware: mindestens 31536000, weil der Core diesen Wert bereits ausliefert.