HSTS-Preload

Was diese Prüfung macht

Schlägt deine Domain in der Chromium-HSTS-Preload-Liste nach — einer statischen Liste HTTPS-only-Domains, die direkt in Chrome, Firefox, Safari, Edge und Brave einkompiliert ist. Für gelistete Domains verweigern Browser Plain-HTTP-Verbindungen ab der allerersten Anfrage, noch bevor irgendein Header gesehen wurde.

Die Prüfung gibt eines zurück: preloaded, pending submission, not preloaded oder removal in progress.

Warum es zählt

HSTS schließt das Downgrade-Angriffsfenster — aber erst, nachdem ein Browser den Header einmal gesehen hat. Der allererste Besuch einer Nutzer:in auf deiner Domain ist weiterhin Klartext. Auf feindlichem WLAN oder mit einem kompromittierten Router kann eine Angreifer:in diese erste Anfrage abfangen, den Redirect auf HTTPS stripen und eine bösartige Version deiner Seite ausliefern, bevor HSTS überhaupt greift.

Preloading eliminiert dieses Fenster. Der Browser weiß vor dem Tippen der URL, dass deine Domain HTTPS-only ist. Selbst auf einer brandneuen Installation ohne History ist die erste Anfrage verschlüsselt.

Das zählt vor allem für: Banking, Healthcare, Konten mit wertvollen Credentials, Payment-Flows und jede Site, bei der der erste Besuch die Nutzer:in kompromittieren könnte. Für eine Marketing-Site ohne Auth ist Preload ein nettes Signal operativer Reife, aber nicht tragend.

Der Trade-off: Preloading ist schwer rückgängig zu machen. Eine Entfernung dauert typischerweise 6–12 Wochen über den Chrome-Stable-Kanal, und Nutzer:innen auf älteren Browser-Versionen bleiben noch länger eingesperrt. Reich es nur ein, wenn du sicher bist, dass deine Domain für immer HTTPS spricht.

So behebst du es

1. Voraussetzungen vor der Einreichung prüfen.

Per hstspreload.org-Policy muss deine Site:

• Ein gültiges HTTPS-Zertifikat auf Apex-Domain und www ausliefern.
• HTTP → HTTPS auf demselben Host weiterleiten (siehe HTTP auf HTTPS weiterleiten).
• Auf jeder HTTPS-Response einen HSTS-Header senden mit:
  • max-age ≥ 31536000 (ein Jahr)
  • includeSubDomains
  • preload
• Alle Subdomains ebenfalls über HTTPS ausliefern — includeSubDomains meint das ernst.

Der produktionsreife Header:

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

Zwei Jahre ist der übliche Wert, sobald du sicher bist.

2. Header konfigurieren.

nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Apache:

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

Cloudflare: SSL/TLS → Edge Certificates → HSTS → max-age auf 12+ Monate setzen, Include subdomains aktivieren, Preload aktivieren, No-Sniff Header aktivieren.

3. Vor der Einreichung verifizieren.

curl -sI https://yourdomain.com | grep -i strict-transport-security
curl -sI https://www.yourdomain.com | grep -i strict-transport-security
curl -sI https://anysubdomain.yourdomain.com | grep -i strict-transport-security

Alle drei sollten den Header mit allen drei Direktiven zurückgeben. Fehlt einer Subdomain der Header oder liefert sie nicht über HTTPS, wird die Einreichung abgelehnt.

4. Auf hstspreload.org einreichen.

Trag die Domain auf hstspreload.org ein, akzeptiere die Warnungen, klick Submit. Das Formular läuft dieselbe Verifizierung wie die manuelle Prüfung oben. Genehmigte Domains landen im nächsten Chrome-Release (6–12 Wochen bis Stable). Firefox, Safari und Edge ziehen die Chromium-Liste in ihrer eigenen Taktung.

5. Plan für den Worst Case, bevor du einreichst.

Geh diese Fehlermodi durch und bestätige für jeden, dass er okay ist:

• Cert läuft unbemerkt ab. Nutzer:innen bekommen einen harten Fehler ohne HTTP-Fallback. Automatisiere die Erneuerung (Let’s Encrypt + certbot-Timer oder den Managed Cert deines Cloud-Providers).
• Subdomain braucht HTTP (Legacy-Gerät, IoT, internes Tool). Geht nicht. Du bist auf HTTPS überall für die eTLD+1 festgenagelt.
• Übernahme / Domain verkauft. Der neue Eigentümer erbt den Preload-Eintrag bis zur Entfernung. Käufer:innen sollten vor dem Kauf die Preload-Liste prüfen.
• Interne Domain versehentlich eingereicht. Entfernung dauert Monate. Reich nur öffentliche Produktionsdomains ein.

6. Entfernung, falls du sie je brauchst.

Reiche einen Removal-Request auf hstspreload.org ein. Die Domain fliegt mit dem nächsten Chromium-Update raus (~6 Wochen). Ältere Browser-Installationen bleiben so lange gesperrt, wie ihre max-age sagt — Nutzer:innen, die Chrome nicht updaten, können ein Jahr oder länger feststecken. Senk max-age weit im Voraus auf einen kleinen Wert (z. B. 300), um den verbleibenden Lock-in zu begrenzen.

Häufig gestellte Fragen

Brauche ich Preload, wenn ich schon HSTS habe?

Für die meisten Marketing-Sites nein. Reines HSTS schützt alle nach ihrem ersten Besuch — gut genug, wenn es keine Auth oder Payment-Flows gibt. Preload zählt, wenn (a) du Credentials, Geld oder PHI verarbeitest, (b) du HTTPS für immer garantieren kannst und (c) du HSTS schon ein paar Monate ohne Probleme ausgespielt hast.

Wie lange bis es in Chrome wirklich erscheint?

Einreichung bis erste Chrome-Stable-Veröffentlichung: typischerweise 6–12 Wochen. Das Formular zeigt “pending”, bis die Liste neu kompiliert wird, dann “pending preload”, während es durch Chromes Release-Kanäle (canary → dev → beta → stable) wandert. Firefox, Safari und Edge ziehen die Chromium-Liste in eigenen Update-Zyklen — rechne mit 3–6 Monaten für breite Abdeckung.

Kann ich nur eine Subdomain preloaden, etwa app.example.com?

Ja, aber nur, wenn die übergeordnete eTLD+1 noch nicht preloaded ist. Reich app.example.com direkt ein. Dieselben Voraussetzungen gelten (HSTS-Header mit Preload-Direktive, HTTPS überall auf diesem Hostnamen). Das ist der richtige Ansatz, wenn du eine Subdomain kontrollierst, aber die ganze Organisation nicht auf HTTPS-für-immer festnageln kannst.