HSTS-Preload: Voraussetzungen und Risiken vor dem Eintrag

Was die HSTS-Preload-Liste ist

Ein HSTS-Header weist den Browser an, eine Domain für die Dauer von max-age nur noch über HTTPS aufzurufen. Die Schwäche liegt im ersten Kontakt: HSTS greift erst, nachdem der Browser mindestens einmal eine sichere Verbindung aufgebaut und den Header erhalten hat (MDN). Bis dahin kann ein Angreifer im selben Netz den ersten, unverschlüsselten Aufruf abfangen. RFC 6797 beschreibt als Gegenmittel eine Liste, die Browser ab Werk mitbringen, ähnlich wie die Stammzertifikate der Zertifizierungsstellen (RFC 6797).

Diese Liste wird für Chrome gepflegt und ist in den Browser eingebaut. Anfragen an eingetragene Domains laufen nur über HTTPS; jede HTTP-Anfrage wird umgestellt und schlägt fehl, wenn HTTPS nicht verfügbar ist (hstspreload.org). Firefox, Safari und Edge führen eigene Preload-Listen, die auf der Chrome-Liste beruhen (hstspreload.org). Zur HSTS-Spezifikation gehört die Liste nicht, und sie soll nach MDN auch nicht als offiziell betrachtet werden (MDN).

Wichtig ist die Trennung zwischen Direktive und Eintrag. Die Spezifikation kennt preload nicht, in RFC 6797 ist die Direktive nicht definiert (RFC 6797). Sie richtet sich an die Betreiber der Liste: Sendet eine Website sie, gilt das als Antrag auf Aufnahme, und die Domain darf über das Formular auf hstspreload.org eingereicht werden (hstspreload.org). Geschützt ist eine Domain erst, wenn sie tatsächlich auf der Liste steht und diese Liste mit einem Update beim Nutzer angekommen ist. Neue Einträge werden fest in den Chrome-Quellcode übernommen und können mehrere Monate brauchen, bis sie die stabile Version erreichen (hstspreload.org).

Wie verbreitet die Direktive ist, zeigt der Web Almanac des HTTP Archive: 36 Prozent der mobil aufgerufenen Seiten senden einen HSTS-Header (Web Almanac 2025). Von den Seiten mit HSTS setzen rund 40 Prozent includeSubDomains und etwa 22 Prozent die Direktive preload (Web Almanac 2025). Wie viele davon tatsächlich eingereicht wurden, verrät die Zahl nicht. Sie zeigt aber, wie oft preload ausgeliefert wird; ob dahinter jeweils eine bewusste Entscheidung steht, lässt sich von außen nicht ablesen.

Warum der Zusatznutzen kleiner geworden ist

Die Preload-Liste entstand für ein Problem, das Browser inzwischen auch auf anderem Weg angehen. Viele Browser, darunter Chrome und Safari, stellen HTTP-Navigationen automatisch auf HTTPS um, unabhängig von der HSTS-Richtlinie einer Domain. Preloading bringt nach Darstellung von hstspreload.org nur dann zusätzlichen Schutz, wenn diese Umstellung durch einen aktiven Angreifer scheitert (hstspreload.org).

Für Chrome hat Google im Oktober 2025 angekündigt, mit Chrome 154 die Einstellung „Always Use Secure Connections“ standardmäßig einzuschalten, geplant für Oktober 2026 (Google Security Blog). Chrome soll dann vor dem ersten Aufruf einer öffentlichen Website ohne HTTPS nachfragen. Was die Chrome-HTTPS-Pflicht für Websites bedeutet, haben wir gesondert beschrieben. Der Unterschied zu HSTS liegt im Ausweg: In diesem Modus zeigt Chrome eine Warnung, die sich überspringen lässt, wenn HTTPS nicht verfügbar ist (Google Security Blog).

Bei einer HSTS-Domain gibt es diesen Ausweg nicht. Tritt beim Verbindungsaufbau ein TLS-Fehler auf, etwa ein ungültiges Zertifikat, bietet der Browser keine Möglichkeit, die Fehlermeldung zu übergehen (MDN). RFC 6797 nennt das „no user recourse“: Wer eine HSTS-Richtlinie ausliefert, entscheidet sich damit für einen Verbindungsabbruch bei jedem Zertifikatsfehler (RFC 6797). Mit einem Preload-Eintrag gilt das für jeden Besucher, auch beim allerersten Aufruf, und für jede Subdomain.

Genau diese Härte ist der Kern der Abwägung. HTTPS-First schützt die meisten Erstaufrufe und lässt bei Problemen einen Ausweg. Der Preload-Eintrag schützt zusätzlich gegen einen Angreifer, der die Umstellung aktiv verhindert, nimmt aber jedem Besucher den Ausweg, sobald irgendeine Subdomain kein gültiges Zertifikat hat. Für Domains mit hohem Angriffsdruck und vollständig kontrollierter Infrastruktur kann sich das lohnen. Für eine Firmendomain, unter der auch Intranet, Gerätezugänge und alte Kampagnenseiten hängen, überwiegt in der Regel das Risiko.

Die Voraussetzungen für den Eintrag

Die Bedingungen stehen auf hstspreload.org im Abschnitt „Submission Requirements“. Sie sind kurz, reichen aber weit über die Startseite hinaus:

• Gültiges Zertifikat für die Domain (hstspreload.org).
• Weiterleitung von HTTP auf HTTPS auf demselben Host, sofern der Server auf Port 80 erreichbar ist (hstspreload.org). http://example.com muss also zuerst auf https://example.com zeigen, nicht direkt auf https://www.example.com.
• Alle Subdomains über HTTPS, insbesondere www, sobald dafür ein DNS-Eintrag existiert (hstspreload.org).
• HSTS-Header auf der Basisdomain mit max-age von mindestens 31.536.000 Sekunden, also einem Jahr, dazu includeSubDomains und preload (hstspreload.org).
• Header auch auf Zwischenweiterleitungen: Leitet die HTTPS-Seite noch einmal weiter, etwa auf www, muss bereits diese Weiterleitung den Header tragen, nicht erst die Zielseite (hstspreload.org).

Das Beispiel auf hstspreload.org nutzt max-age=63072000, also zwei Jahre (hstspreload.org). Ein Jahr ist das Minimum, kein Zielwert. Im Web liegt der Median der gültigen max-age-Werte laut Web Almanac 2025 bei genau einem Jahr (Web Almanac 2025). Ob Ihre Weiterleitungskette die Bedingung „gleicher Host zuerst“ erfüllt, zeigt eine einzelne Abfrage; sie steht weiter unten bei den Stufen.

Zwei Details scheitern in der Praxis häufiger als die Werte selbst. Erstens zählt nur die erste HSTS-Zeile einer Antwort: Erhält ein Browser mehrere, verarbeitet er nur die erste (RFC 6797). Setzen Anwendung und vorgeschalteter Proxy je eine eigene Zeile, wendet der Browser womöglich eine andere Richtlinie an als die, die Sie geprüft haben, und die Prüfung von hstspreload.org wertet mehrere HSTS-Zeilen als Fehler (chromium/hstspreload). Zweitens gehört der Header nur in HTTPS-Antworten; über HTTP empfangen, muss der Browser ihn ignorieren (RFC 6797). Welche Kopfzeilen tatsächlich ausgeliefert werden, zeigt der HTTP-Header-Inspektor.

# HTTP: nur weiterleiten, kein HSTS-Header
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

# HTTPS: genau eine HSTS-Zeile, auch auf Weiterleitungen und Fehlerseiten
server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=2592000; includeSubDomains" always;
    # preload erst nach einer bewussten Entscheidung ergänzen
}

Subdomains erfassen, bevor der Eintrag sie erfasst

Der folgenreichste Satz der Voraussetzungen steht als Anmerkung darunter: Das Preloading gilt für alle Subdomains, auch für interne, die nicht öffentlich erreichbar sind (hstspreload.org). Beim Einreichen bestätigt der Betreiber, dass danach alle Subdomains und verschachtelten Subdomains, also .example.com und .*.example.com, ohne gültiges HTTPS-Zertifikat nicht mehr aufrufbar sind (hstspreload.org). Betroffen ist damit auch ein Name wie drucker.lager.example.com, der nur im Firmennetz auflöst.

Die Inventur gehört deshalb vor den Antrag. Keine Quelle ist allein vollständig, sinnvoll ist es, mehrere zusammenzuführen:

Zwei technische Details machen die Inventur strenger, als sie zunächst wirkt. HSTS gilt für alle Ports eines Hosts, unabhängig davon, über welchen Port die Anfrage kam (MDN). Ein Dienst, der unter intern.example.com:8080 nur HTTP spricht, ist damit genauso betroffen wie die Website. Und RFC 6797 beschreibt ausdrücklich Dienste, die bewusst über HTTP laufen, etwa Sperrlisten und OCSP einer Zertifizierungsstelle unter einer Subdomain: Setzt die übergeordnete Domain includeSubDomains, können Browser sie nicht mehr abrufen (RFC 6797).

max-age in Stufen anheben

hstspreload.org empfiehlt, max-age nicht sofort auf ein Jahr zu setzen, sondern in Stufen hochzufahren, jeweils schon mit includeSubDomains (hstspreload.org). Davor steht ein Schritt, der leicht übersprungen wird: alle Subdomains und verschachtelten Subdomains darauf prüfen, ob sie über HTTPS funktionieren, ausdrücklich einschließlich der internen (hstspreload.org).

1. 5 Minuten: max-age=300; includeSubDomains
2. 1 Woche: max-age=604800; includeSubDomains
3. 1 Monat: max-age=2592000; includeSubDomains
4. Danach: mindestens ein Jahr mit includeSubDomains; preload erst, wenn die Entscheidung für den Eintrag gefallen ist.

In jeder Stufe sollen Sie auf defekte Seiten achten und die Kennzahlen der Website beobachten, etwa Besuche und Umsatz, Probleme beheben und danach die volle Laufzeit der Stufe abwarten, in der letzten Stufe also einen Monat (hstspreload.org). Der Sinn: Eine fehlerhafte Regel bleibt bei Besuchern nur so lange gespeichert, wie max-age es vorgibt. Ein Fehler in der ersten Stufe ist nach Minuten vergessen, ein Fehler mit einem Jahr Laufzeit nicht.

Wichtig für den Rückweg: max-age=0 beendet HSTS im Browser, einschließlich includeSubDomains (RFC 6797). Das wirkt aber nur bei Browsern, die die Domain danach noch einmal über HTTPS erreichen, denn über unverschlüsseltes HTTP lässt sich HSTS nicht abschalten (MDN). Für die Preload-Liste ersetzt max-age=0 keinen Austragungsantrag; dazu weiter unten mehr. Den Stand jeder Stufe prüfen Sie am schnellsten auf der Kommandozeile:

Die erste Abfrage zählt die HSTS-Zeilen; mehr als eine ist ein Befund. Die zweite zeigt den Wert, den der Browser übernimmt. Die dritte prüft, ob die HTTP-Weiterleitung auf demselben Host bleibt. Für Subdomains gehört dieselbe Abfrage in eine Schleife über die Inventurliste.

Der Antrag und die Zeit danach

Eingereicht wird über das Formular auf hstspreload.org. Es prüft die Voraussetzungen und meldet bei Erfolg, dass die Domain zur Aufnahme vorgemerkt ist. Ab dann muss die Domain die Voraussetzungen dauerhaft erfüllen, sonst wird sie wieder entfernt (hstspreload.org). Wer preload später aus dem Header nimmt, macht die Domain sofort antragsberechtigt für die Austragung, und Domains, die die Anforderungen nicht mehr erfüllen, können künftig automatisch entfernt werden (hstspreload.org).

Den Stand Ihrer Domain zeigt der kostenlose SSL-Check. Sendet die Domain einen HSTS-Header, wertet er ihn aus und fragt den Listenstatus bei hstspreload.org ab, etwa „gelistet“, „Aufnahme beantragt“, „Entfernung beantragt“ oder „nicht gelistet“. Konnte die Abfrage nicht beantwortet werden, steht dort „nicht ermittelt“ statt eines geratenen Status.

Für die Zeitplanung lohnt ein Blick auf den Release-Zyklus von Chrome. Eine neue Hauptversion erscheint alle zwei Wochen im stabilen Kanal (Chromium). Unternehmen, die den Extended-Stable-Kanal nutzen, erhalten eine neue Hauptversion nur alle acht Wochen (Chromium). Ein Listeneintrag, der über den Quellcode in den Browser wandert, kommt deshalb nicht am nächsten Tag bei allen Nutzern an. Für eine Austragung gilt dasselbe, nur in umgekehrter Richtung.

Austragung: der lange Weg zurück

Den Abschnitt zur Austragung leitet hstspreload.org mit einem deutlichen Satz ein: Die Aufnahme in die Preload-Liste lässt sich nicht ohne Weiteres rückgängig machen (hstspreload.org). Domains können entfernt werden, doch es dauert Monate, bis eine Änderung mit einem Chrome-Update bei den Nutzern ankommt, und für andere Browser gibt es keine Zusage (hstspreload.org).

Konkreter wird die Austragungsseite: Eine Entfernung kann 6 bis 12 Wochen brauchen, bis sie die meisten Chrome-Nutzer erreicht, und bei anderen Browsern länger (hstspreload.org). Über das Austragungsformular beantragen kann sie nur, wer weiterhin HTTPS mit gültigem Zertifikat und einen gültigen HSTS-Header ohne preload ausliefert (hstspreload.org). Wer ein Problem lösen will, indem er HTTPS auf der Hauptdomain abschaltet, verbaut sich damit auch diesen Weg zur Austragung.

Der eigentliche Schaden entsteht in der Zwischenzeit: Jede Subdomain ohne gültiges Zertifikat bleibt für Besucher mit aktuellem Browser gesperrt, bis die Austragung bei ihnen angekommen ist. hstspreload.org erklärt, Austragungswünschen in der Regel nachzukommen, wenn eine Subdomain aus triftigen technischen oder Kostengründen nicht über HTTPS laufen kann (hstspreload.org). Schneller als die Austragung ist meist der umgekehrte Weg: die betroffene Subdomain mit einem Zertifikat versorgen. Wie sich Zertifikate automatisch ausstellen und die Erneuerung prüfen lässt, zeigt der Beitrag zur ACME-Erneuerung.

Einreichen, warten oder verzichten

Am Ende steht eine Abwägung, die sich mit wenigen Fragen ordnen lässt. Ein Eintrag kommt in Betracht, wenn alle folgenden Punkte zutreffen:

• Die Domain und alle heutigen Subdomains liefern HTTPS mit gültigem Zertifikat, intern wie extern.
• Neue Subdomains entstehen nur über einen Ablauf, der HTTPS von Anfang an vorsieht.
• Unter der Domain laufen keine Fremddienste, deren HTTPS Sie nicht steuern.
• Die Stufen bis zu einem Jahr max-age sind ohne Befund durchlaufen.
• Eine Person oder ein Team ist dauerhaft zuständig und weiß, dass der Rückweg Monate dauert.

Eher verzichten sollten Sie, wenn die Domain zugleich Firmennetz, Geräte und Dienste von Partnern trägt, wenn eine Agentur nur die Website betreut, aber nicht DNS und interne IT, oder wenn niemand sagen kann, welche Subdomains es gibt. Ein HSTS-Header mit includeSubDomains und einem Jahr Laufzeit bringt den größeren Teil des Nutzens ohne die feste Bindung (hstspreload.org), denn ein Fehler lässt sich dort über max-age und neue Antworten wieder einfangen. Die Subdomain-Inventur braucht es trotzdem: includeSubDomains wirkt bei wiederkehrenden Besuchern genauso auf jede Subdomain.

Die HSTS-Zeile laufend im Blick behalten

Ob eingetragen oder nicht: Die HSTS-Zeile ist Konfiguration, die sich mit jedem Server-, Proxy- oder CDN-Wechsel ändern kann. Der Security-Scan von XICTRAQ® wertet sie so aus, wie ein Browser sie anwendet: Nur die erste Zeile zählt, eine Zeile mit Syntaxfehler gilt als unwirksam, und max-age=0 wird als Ende von HSTS gemeldet. Für eine preload-fähige Zeile, also genau eine Zeile mit mindestens einem Jahr, includeSubDomains und preload, vergibt der Score Zusatzpunkte. Sendet der Server mehrere HSTS-Zeilen, erscheint eine Warnung mit dem Hinweis, dass Browser nur die erste anwenden und hstspreload.org mehrere ablehnt.

Der Bonus bewertet die Zeile, nicht den Eintrag. XICTRAQ® trägt keine Domain in die Liste ein oder aus; die Entscheidung bleibt bei Ihnen und folgt den Kriterien oben. Ein besserer Score ist kein Grund für einen Antrag. Unterschreitet der Score einen Mindestwert, den Sie in den Benachrichtigungen festlegen, werden Sie alarmiert.

Für die Inventur hilft das DNS- und Domain-Monitoring: XICTRAQ® kann bekannte Subdomains über Certificate-Transparency-Logs entdecken und zur Überwachung vorschlagen, und jede Subdomain lässt sich als eigene Website überwachen, im Rahmen der Website-Anzahl Ihres Plans. So fällt ein Zertifikatsproblem auf einer Subdomain auf, bevor Besucher es melden. Damit eine solche Meldung nachts nicht ungelesen bleibt, lohnt es sich, die Alarmkette regelmäßig zu testen.

Preload ist eine Zusage auf Jahre

Ein Eintrag in die HSTS-Preload-Liste ist schnell beantragt und braucht Wochen bis Monate, um wieder zu verschwinden. Wer ihn erwägt, sollte die Reihenfolge einhalten: zuerst HSTS ohne preload nach den Grundlagen der Security-Header sauber einführen, Mixed Content beseitigen und die TLS-Konfiguration prüfen, dann alle Subdomains erfassen und max-age stufenweise anheben. Erst wenn jede Subdomain HTTPS spricht und jemand dauerhaft dafür zuständig ist, ist preload eine Entscheidung und keine Zeile aus einer Vorlage.