HSTS: Der vollständige Leitfaden zur Aktivierung von Strict-Transport-Security und der Preload-Liste

Von CaptainDNS
Veröffentlicht am 24. April 2026

HSTS und Preload-Liste: die Strict-Transport-Security-Direktiven, die HTTPS erzwingen

TL;DR

HSTS (RFC 6797) weist den Browser an, eine Domain während der durch max-age definierten Dauer nur über HTTPS zu kontaktieren, und neutralisiert so sslstrip-Angriffe und Protokoll-Downgrades
Der Header besteht aus drei Direktiven: max-age (verpflichtend), includeSubDomains (deckt Subdomains ab) und preload (Opt-in für die in Chrome und Derivaten eingebettete Liste)
Für die Preload-Liste benötigst du max-age größer oder gleich 31 536 000, includeSubDomains, preload sowie eine HTTP-zu-HTTPS-Weiterleitung auf der Apex-Domain
Die Preload-Liste ist nahezu unumkehrbar: ein Austrag dauert mehrere Monate und betrifft nur künftige Browserversionen
Im April 2026 sind rund 120 000 Domains in der Chrome-Preload-Liste enthalten und nur 35,7 % der Websites mit HSTS aktivieren die Direktive preload

2009 stellt Moxie Marlinspike auf der Black Hat DC sslstrip vor. Das Tool fängt den HTTP-Verkehr eines Nutzers in einem öffentlichen Netzwerk ab, ersetzt im Vorbeigehen jeden HTTPS-Link und jede HTTPS-Weiterleitung durch das HTTP-Äquivalent und leitet die Anfragen im Klartext weiter. Der Nutzer glaubt, durch TLS geschützt zu sein, während sein gesamter Verkehr inklusive Session-Cookies und Passwörter unverschlüsselt über die Leitung geht. Etwa zur selben Zeit popularisiert die Firefox-Extension Firesheep (Oktober 2010) den Diebstahl von Sessions auf Facebook und Twitter aus jedem offenen WLAN-Hotspot.

HSTS (HTTP Strict Transport Security) ist die Antwort auf diese Angriffe. Standardisiert durch RFC 6797 im November 2012, erlaubt der Header einem HTTPS-Server dem Browser mitzuteilen, dass er während einer festgelegten Dauer ausschließlich über HTTPS mit der Domain kommunizieren soll. Sobald der Header empfangen und gespeichert wurde, wandelt der Browser jede http://-Anfrage lokal in https:// um, bevor auch nur ein einziges Paket im Netzwerk versendet wird. Das Zeitfenster für die Abfangung bei der ersten Weiterleitung verschwindet.

Im April 2026 nutzen laut den Adoptionsstudien von AppSecSanta nur 35,7 % der Websites mit HSTS-Header die Direktive preload. Die Chrome HSTS Preload List enthält rund 120 000 Domains, weit entfernt vom weltweiten HTTPS-Bestand. HSTS bleibt daher untergenutzt, oft falsch konfiguriert und zuweilen mit unerwarteten Nebeneffekten auf interne Subdomains in HTTP aktiviert.

Dieser Leitfaden verfolgt drei Ziele: präzise verstehen, was HSTS leistet (und was nicht), den Header in den fünf gängigsten Web-Stacks konfigurieren und eine Domain sauber in die Preload-Liste einreichen, ohne die Infrastruktur zu zerstören. Er richtet sich an DevOps, SREs, Systemadministratoren und CTOs von KMU, die ein Sicherheitsaudit oder eine Preload-Einreichung vorbereiten.

Was ist HSTS?

HSTS ist ein HTTP-Antwort-Header, der von einem gültigen HTTPS-Server ausgeliefert wird. Er teilt dem User-Agent (Browser, HTTP-Bibliothek, RFC-6797-konformer Automatisierungsagent) mit, dass die Domain während der durch max-age festgelegten Dauer ausschließlich über HTTPS kontaktiert werden muss.

Sobald der Header über eine gültige TLS-Verbindung empfangen wurde, speichert der Browser lokal einen sogenannten "Known HSTS Host". Bei jeder weiteren Anfrage an diese Domain, einschließlich solcher, die durch einen Klick auf einen http://-Link, ein gespeichertes Lesezeichen oder eine 301-Weiterleitung von einem anderen Server ausgelöst werden, schreibt der Browser die URL vor dem Senden in https:// um. Die Umwandlung erfolgt im Speicher, auf Client-Seite, ohne zwischengeschaltete Netzwerkanfrage.

Drei Elemente machen HSTS wirksam:

Die Umwandlung erfolgt lokal. Es wird niemals eine HTTP-Anfrage an eine als HSTS bekannte Domain abgesetzt. Ein Angreifer in einer Man-in-the-Middle-Position sieht nur TLS.
Zertifikatsfehler sind fatal. Auf einer HSTS-Domain entfernt der Browser den Button "Trotzdem fortfahren", den der Nutzer bei einem TLS-Fehler anklicken könnte. Ein von einem Angreifer eingeschleustes selbstsigniertes Zertifikat löst eine Blockade aus, keine Warnung.
Die TTL auf Browserseite wird bei jedem Besuch verlängert. Solange der Nutzer die Website regelmäßig besucht, wird max-age bei jeder Antwort aufgefrischt, was den Ablauf verhindert.

Der Header ist standardisiert und wird von allen großen Browsern seit 2011 unterstützt. Chromium 4.0.211, Firefox 4.0 (August 2010), Opera 12, Safari unter OS X 10.7.3, Edge von Beginn an und Internet Explorer 11 implementieren ihn. Im April 2026 ist die Kompatibilität universell: 98 % des weltweiten Web-Traffics laufen über einen HSTS-kompatiblen Browser.

Die drei Schutzschichten von HSTS: max-age für die Dauer, includeSubDomains für die Subdomains, preload für den Eintrag in die Browser

Das Problem, das HSTS löst

sslstrip und das Protokoll-Downgrade

Ohne HSTS hat der HTTPS-Schutz einer Website ein schwaches Glied: die erste Anfrage. Wenn ein Nutzer captaindns.com in die Adressleiste tippt, sendet der Browser standardmäßig eine HTTP-Anfrage über Port 80. Der Server antwortet mit einer 301-Weiterleitung auf https://captaindns.com. Diese erste Anfrage geht im Klartext raus. Ein Angreifer im lokalen Netzwerk kann sie abfangen.

Der sslstrip-Angriff funktioniert so: Der Angreifer positioniert sich zwischen Nutzer und Netzwerk-Gateway (ARP-Spoofing, Rogue Access Point, DHCP-Kompromittierung). Er fängt die initiale HTTP-Anfrage ab, leitet sie via HTTPS an den legitimen Server weiter, empfängt die Antwort, ersetzt sämtliche https:// durch http:// in HTML, Headern und Cookies und schickt sie unverschlüsselt an den Nutzer zurück. Aus Sicht des Browsers sieht alles normal aus: eine klassische HTTP-Seite ohne Fehler. Der Nutzer gibt sein Passwort ein, das im Klartext bis zum Angreifer gelangt und dann verschlüsselt an den Server weitergeleitet wird.

HSTS neutralisiert sslstrip für nachfolgende Besuche. Nach der ersten erfolgreichen HTTPS-Anfrage speichert der Browser den Header. Der zweite Besuch, selbst wenn er mit einem Klick auf einen http://-Link oder einer Weiterleitung von einer Drittdomain beginnt, geht niemals als HTTP raus. Der Browser wandelt die URL lokal um, vor dem DNS, vor dem connect(), vor jeglichem Netzwerkverkehr.

Die Grenze bleibt der allererste Besuch. Ein Browser, der den HSTS-Header für eine Domain noch nie erhalten hat, ist bei seiner ersten Anfrage anfällig für sslstrip. Genau das korrigiert die Preload-Liste: die in Chrome eingebettete Liste erlaubt es dem Browser, HSTS-Domains schon ab Werk zu kennen, ohne auf eine erste Verbindung warten zu müssen.

Firesheep, im Oktober 2010 veröffentlicht, hat im großen Maßstab demonstriert, wie trivial der Session-Diebstahl in öffentlichen Netzwerken ist. Die Extension schnüffelte Session-Cookies von Facebook, Twitter, Flickr und vielen weiteren Websites mit, die ihre authentifizierten Nutzer noch über HTTP auslieferten (oder die nur für die Login-Seite auf HTTPS umstiegen und dann auf HTTP zurückfielen). In einem Café-WLAN reichte ein Klick auf einen Nutzer in der Firesheep-Oberfläche, um Zugang zu seinem Konto zu erlangen.

HSTS verstärkt den Cookie-Schutz auf zwei Wegen. Zum einen eliminiert das Erzwingen von HTTPS das Auslaufen des Cookies über eine unverschlüsselte Verbindung. Zum anderen schließt HSTS in Kombination mit dem Secure-Attribut auf dem Cookie (das den Versand über HTTP verbietet) und HttpOnly (das den JavaScript-Zugriff blockiert) die drei Hauptvektoren für Netzwerk-Sessiondiebstahl.

Mit der Direktive includeSubDomains schützt HSTS auch Cookies, die ohne explizite Domainangabe gesetzt werden. Ein von www.captaindns.com ohne Secure gesetzter Cookie könnte ohne HSTS via HTTP an api.captaindns.com gesendet werden, wenn dort eine Subressource im Klartext geladen wird. Mit includeSubDomains werden alle Anfragen an beliebige Subdomains in HTTPS erzwungen, und der Cookie bleibt verschlüsselt.

Bootstrap-MITM und die Preload-Liste

RFC 6797 §14.6 erkennt explizit die Verwundbarkeit des "Bootstrap MITM" an: Ein Nutzer, der eine Domain zum ersten Mal besucht, hat den HSTS-Header noch nicht erhalten, und seine initiale HTTP-Anfrage bleibt abfangbar. Das ist das berüchtigte Erstbesuch-Fenster.

Die Preload-Liste von Chromium löst dieses Problem, indem sie die Liste der HSTS-Domains direkt in den Quellcode des Browsers einbettet. Chrome, Firefox, Safari und Edge importieren diese Liste bei jedem Update. Für eine eingetragene Domain weiß der Browser, dass er bereits bei der allerersten Anfrage HTTPS verwenden muss, ohne die Website jemals besucht zu haben. Das Bootstrap-Fenster verschwindet.

Die Eintragung ist kostenlos, aber anspruchsvoll: max-age größer oder gleich 1 Jahr, includeSubDomains, preload, HTTP-zu-HTTPS-Weiterleitung auf der Apex-Domain. Einmal eingetragen, dauert der Austrag mehrere Monate, weil abgewartet werden muss, bis alle ausgerollten Browserversionen die neue Liste importiert haben. Manche Nutzer auf älteren Versionen werden weiterhin jahrelang HTTPS auf deiner Domain erzwingen.

Anatomie des Strict-Transport-Security-Headers

Die Syntax ist in RFC 6797 §6.1 definiert. Der Header besteht aus einer verpflichtenden Direktive (max-age) und zwei optionalen Direktiven (includeSubDomains, preload), getrennt durch Semikola.

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

Die Direktiven sind Groß-/Kleinschreibungs-unabhängig (IncludeSubDomains ist gültig, aber nicht kanonisch). Eine unbekannte Direktive wird von konformen Browsern stillschweigend ignoriert. Ist die gesamte Syntax ungültig, wird der ganze Header verworfen: ein einziger Tippfehler kann deinen Schutz ohne sichtbaren Hinweis abschalten. Daher ist es wichtig, die Konfiguration vor dem Produktiv-Deployment mit einem dedizierten Tool zu testen.

Gültigkeitsregeln

Mehrere strikte Regeln aus RFC 6797 beeinflussen das Deployment:

HTTPS verpflichtend. Ein über HTTP empfangener HSTS-Header wird ignoriert (§8.1). Diese Regel ist entscheidend: Sie verhindert, dass ein Man-in-the-Middle-Angreifer ein max-age=0 über HTTP einschleust, um HSTS bei einem Opfer zu deaktivieren.
Gültiges Zertifikat verpflichtend. Der Header wird nur berücksichtigt, wenn die TLS-Verbindung ohne Fehler oder Warnung zustande kam (§8.1). Ein abgelaufenes Zertifikat, ein falscher Domainname, eine unvollständige Kette: all das verhindert die Speicherung.
Nur das erste Vorkommen. Werden mehrere HSTS-Header in derselben Antwort gesendet, wird nur der erste verarbeitet (§8.1). Vorsicht bei Middlewares, CDNs und Reverse Proxies, die ihre eigenen Header stapeln.
Keine IP-Adressen. HSTS gilt nur für Domainnamen. Eine über https://192.168.1.1 erreichbare Website ist nicht betroffen (§8.3).
Alle Ports. HSTS deckt die Domain für alle Ports ab. Port 80 wird automatisch in 443 umgewandelt, ein benutzerdefinierter Port behält jedoch seine Nummer.

Drei kanonische Beispiele

# Mindestlösung: 1 Jahr, ohne Subdomains
Strict-Transport-Security: max-age=31536000

# OWASP-Empfehlung: 1 Jahr mit Subdomains
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Preload-fähig: 2 Jahre mit Subdomains und Preload-Opt-in
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Die dritte Zeile ist die Zielkonfiguration für jede öffentliche Website, die maximalen Schutz wünscht. Wir gehen sie Abschnitt für Abschnitt durch.

max-age: die Laufzeit der Policy

max-age ist die einzige verpflichtende Direktive. Sie drückt in Sekunden die Dauer aus, während der der Browser die Domain als "Known HSTS Host" betrachten soll. Einige typische Werte:

Wert	Dauer	Verwendung
0	Sofort	Aufhebung der HSTS-Policy
300	5 Minuten	Initialer Test, vorsichtiger Rollout
3600	1 Stunde	Staging, kurze Validierung
86 400	1 Tag	Schrittweiser Rollout, T+1
604 800	1 Woche	Schrittweiser Rollout, Woche 1
31 536 000	1 Jahr	Mindestschwelle Preload-Liste (seit 11. Oktober 2017)
63 072 000	2 Jahre	Gängige Empfehlung für Preload

Der Zähler wird bei jeder HTTPS-Antwort, die den Header enthält, zurückgesetzt. Konkret: Wenn deine Website max-age=31536000 ausliefert und ein Nutzer einmal pro Monat eine Seite besucht, läuft die Policy nie ab, solange er innerhalb des Jahres zurückkehrt. Umgekehrt: Wenn du den Header abrupt entfernst, werden Browser, die die Policy empfangen haben, weiterhin HTTPS bis zum lokalen Ablauf erzwingen. Das ist ein Sperrklinken-Effekt: HSTS lässt sich nur in eine Richtung leicht aktivieren.

Empfohlener schrittweiser Rollout

OWASP und cio.gov empfehlen eine schrittweise Aktivierung, um nicht mit einer einjährigen Policy auf einer noch im Aufbau befindlichen Website zu landen. Ein typischer Plan:

Tag 0: max-age=300. 5 Minuten. Prüfe, ob die HTTPS-Kette funktioniert, ob die HTTP-zu-HTTPS-Weiterleitung stabil ist und ob alle internen Inhalte über HTTPS ausgeliefert werden. Ein Rückzug ist trivial, die Policy läuft in 5 Minuten ab.
Tag 1: max-age=86 400. 1 Tag. Beobachte die TLS-Fehler, die dein Monitoring-System, deine WAF und deine Anwendungslogs 24 Stunden lang melden. Achte besonders auf gebrochene Weiterleitungen zu internen Ressourcen.
Tag 7: max-age=604 800. 1 Woche. Bleibt die TLS-Fehlerquote stabil, gehe auf eine Woche. Dieser Schritt validiert, dass alle aktiven Subdomains über HTTPS erreichbar sind.
Tag 14: max-age=31 536 000. 1 Jahr. Die Policy ist stabil, die Nutzer sind geschützt. Wenn du die Preload-Liste anstrebst, kannst du in dieser Phase nach einem Audit includeSubDomains und preload aktivieren.

Dieses Tempo erlaubt es, in jeder Phase zurückzukehren. Ein direkter Sprung auf 1 Jahr ohne Zwischentest ist der häufigste Fehler: Wenn eine einzige vergessene Subdomain nach Aktivierung von includeSubDomains bricht, bist du auf Browserseite ein Jahr lang blockiert.

Deaktivierung über max-age=0

RFC 6797 §6.1.1 legt fest, dass der Wert 0 dem Browser signalisiert, die zwischengespeicherte Policy zu löschen. Das ist die einzige Möglichkeit, HSTS sauber zu entfernen: während der vorherigen Laufzeit einen Header mit max-age=0 ausliefern, abwarten, bis die Browser dieses Update empfangen, und dann den Header vollständig entfernen. Achtung: Diese Deaktivierung ist nur über HTTPS wirksam (§8.1). Ein über HTTP ausgeliefertes max-age=0 wird ignoriert.

includeSubDomains: den Schutz erweitern

Die Direktive includeSubDomains erweitert die HSTS-Policy auf alle Subdomains des Hostnamens, der sie ausgesendet hat. Von captaindns.com ausgeliefert, deckt sie www.captaindns.com, api.captaindns.com, blog.captaindns.com sowie alle Sub-Subdomains (staging.api.captaindns.com etc.) ab.

RFC 6797 §8.2 legt fest, dass das Matching Label für Label, von rechts nach links und ohne Berücksichtigung der Groß-/Kleinschreibung erfolgt. Eine bei captaindns.com deklarierte HSTS-Policy deckt also die gesamte darunterliegende DNS-Hierarchie ab. Umgekehrt deckt eine bei www.captaindns.com deklarierte Policy weder api.captaindns.com noch captaindns.com ab, weil die Wurzel keine Subdomain von www ist.

Warum das für Cookies kritisch ist

Ohne includeSubDomains kann ein Angreifer HSTS umgehen, indem er eine HTTP-Anfrage an eine Subdomain erzwingt. Klassisches Szenario:

Der Nutzer meldet sich an dem durch HSTS geschützten https://captaindns.com an und erhält einen Session-Cookie ohne Secure-Attribut.
Der Angreifer schleust ein Bild <img src="http://blog.captaindns.com/pixel.png"> in eine vom Opfer besuchte Seite ein (via XSS, ein Forum oder einen Man-in-the-Middle auf einer anderen Website).
Der Browser sendet die Anfrage über HTTP an blog.captaindns.com und hängt automatisch den Cookie der Parent-Domain an (weil sich Cookies an Subdomains weiterverbreiten).
Der Angreifer, der im Netzwerk positioniert ist, fängt den Cookie im Klartext ab.

Mit includeSubDomains wird die Anfrage an blog.captaindns.com vor dem Versand in HTTPS umgewandelt. Der Cookie bleibt auf der Leitung verschlüsselt. Aus diesem Grund empfiehlt das OWASP Cheat Sheet includeSubDomains systematisch, sobald möglich.

Fallstricke, die zu vermeiden sind

includeSubDomains hat einen radikalen Nebeneffekt: alle Subdomains, auch nicht-öffentliche, müssen HTTPS ausliefern. Hier die häufigsten, von DevOps-Communities dokumentierten Fallstricke:

Interne Tools über HTTP. Ein über HTTP im privaten Netzwerk ausgeliefertes grafana.intern.captaindns.com wird für Nutzer unzugänglich, die die HSTS-Policy von captaindns.com bereits gespeichert haben.
Staging-Umgebungen. Ein staging.captaindns.com mit selbstsigniertem Zertifikat verursacht fatale TLS-Fehler für Teams, die sich von Workstations verbinden, die zuvor die Produktion besucht haben.
Historische Subdomains. Ein altes mail.captaindns.com, das von einem Drittanbieter über HTTP ausgeliefert wird, bricht möglicherweise Links in alten E-Mails.
Drittsubdomains. Eine an einen SaaS-Anbieter delegierte Subdomain (z. B. support.captaindns.com, das auf Zendesk zeigt) muss HTTPS mit einem für den delegierten Namen gültigen Zertifikat anbieten.

Bevor du includeSubDomains aktivierst, mach eine vollständige Bestandsaufnahme. Die erfahrensten Teams durchlaufen eine "Shadow Mode"-Phase: HSTS mehrere Wochen lang ohne includeSubDomains aktivieren, mit den DNS-Logs korrelieren, um aktive Subdomains zu identifizieren, und erst nach komplettem Audit umschalten.

Alternative: HSTS auf Subdomain-Ebene

Wenn bestimmte Subdomains nicht auf HTTPS umgestellt werden können (Legacy, externer Vertrag), besteht eine Alternative darin, HSTS einzeln auf jeder Subdomain zu deklarieren, die es kann, ohne includeSubDomains auf der Wurzelebene. Das ist umständlicher, vermeidet aber das Brechen der HTTP-Subdomains. Der Preis: Jede Subdomain muss ihre eigene Policy pflegen, und du kannst ohne includeSubDomains auf dem Apex nicht in die Preload-Liste aufgenommen werden.

preload: die eingebettete Liste

Die Direktive preload ist ein Opt-in, mit dem der Domaininhaber seine Absicht erklärt, in der Chrome HSTS Preload List zu erscheinen. Ohne diese Direktive wird die Domain bei der Einreichung nicht angenommen, selbst wenn sie alle anderen Kriterien erfüllt.

Die vier Eligibilitätskriterien

hstspreload.org verlangt seit dem 11. Oktober 2017, dass der von der Apex-Domain ausgelieferte Header vier Bedingungen erfüllt:

max-age größer oder gleich 31 536 000 (1 Jahr). Ein kürzeres max-age wird abgelehnt.
includeSubDomains vorhanden. Die Preload-Liste deckt immer den vollständigen DNS-Baum ab.
preload vorhanden. Explizite Absichtserklärung.
HTTP-zu-HTTPS-Weiterleitung auf der Apex-Domain. Wenn der Server Verbindungen auf Port 80 akzeptiert, muss er einen 301 auf HTTPS zurückgeben. Auch die Weiterleitung muss den HSTS-Header ausliefern.

Ein gültiges TLS-Zertifikat und die Fähigkeit, alle Subdomains (einschließlich www) über HTTPS auszuliefern, sind ebenfalls erforderlich. Das Einreichungstool prüft diese Bedingungen automatisch, bevor es den Antrag annimmt.

Der Einreichungsprozess

Sind die Bedingungen erfüllt, läuft die Einreichung in drei Schritten ab:

Automatischer Test. Auf hstspreload.org gibst du deine Domain ein. Der Dienst testet den HSTS-Header, die HTTP-zu-HTTPS-Weiterleitung und die HTTPS-Verfügbarkeit der www-Subdomain. Fehler werden detailliert ausgewiesen.
Einreichung. Wenn der Test erfolgreich ist, wird ein Button "Submit to the HSTS preload list" verfügbar. Bestätige, nachdem du die Hinweise zur Unumkehrbarkeit gelesen hast.
Integration. Die Domain wechselt in den Status pending. Sie wird in die Quellliste von Chromium integriert, an Firefox, Safari und Edge weitergegeben. Die vollständige Verbreitung dauert etwa 6 bis 12 Wochen, abhängig von den Release-Zyklen der Browser.

Du kannst den Status jederzeit prüfen via curl https://hstspreload.org/api/v2/status?domain=captaindns.com.

Die Unumkehrbarkeit

Das ist der wichtigste Punkt zum Verstehen. Ist die Domain einmal in der Preload-Liste, dauert ein Austrag mehrere Monate und betrifft nur künftige Browserversionen. Nutzer auf einer alten Version werden weiterhin jahrelang HTTPS auf deiner Domain erzwingen. Das ist besonders störend in drei Fällen:

Domainverkauf. Wenn du captaindns.com an einen Dritten überträgst, der die Domain über HTTP nutzen möchte, verhindert dein Opt-in das.
Stilllegung von Infrastruktur. Wenn du einen Dienst abschaltest und die Domain für etwas anderes genutzt wird, bleibt HSTS im Cache.
Notfall-Rollback. Wenn ein Angriff oder Vorfall deine TLS-Kette beschädigt, kannst du HTTPS nicht im Notfall deaktivieren.

Die Seite hstspreload.org/removal/ dokumentiert die Austragsprozedur. Sie warnt explizit, dass der Prozess mehrere Monate dauern kann und dass manche Nutzer den Austrag nie sehen werden.

Reale Adoption im April 2026

Die Studie APNIC 2023 und die Daten von 2026 zeigen, dass die Adoption trotz der Vorteile gering bleibt:

Statistik	Wert
Domains in der Preload-Liste	~120 000
Größe der eingebetteten Datei	~18 MB
Websites mit HSTS, die preload aktivieren	35,7 %
Top 20 weltweit in der Preload-Liste	8 von 20
Adoption Finanzwesen / Banken	Sehr gering

Google, GitHub, Twitter, Facebook und PayPal stehen auf der Liste. Hingegen haben die Hälfte der 20 größten Websites weltweit kein HSTS auf ihrer Apex-Domain. Regulierte Branchen (Finanzwesen, Gesundheit) hinken hinterher, oft aus Konservativismus bezüglich der Reversibilität.

Schritt-für-Schritt-Anleitung: HSTS pro Stack aktivieren

Wir behandeln hier die fünf am häufigsten ausgerollten Umgebungen im Jahr 2026. Für jeden Stack gibt die Konfiguration zunächst die Mindestlösung an, dann die Preload-fähige Version.

Nginx

In Nginx wird der HSTS-Header über die Direktive add_header im server-Block ausgegeben, der auf Port 443 lauscht. Der Parameter always ist essenziell: Ohne ihn fügt Nginx den Header nur bei 2xx- und 3xx-Antworten hinzu und vergisst ihn bei 4xx und 5xx. Ein Angreifer könnte dann einen 404-Fehler erzwingen, um den Schutz zu umgehen.

Minimalkonfiguration:

server {
    listen 443 ssl http2;
    server_name captaindns.com;

    ssl_certificate /etc/letsencrypt/live/captaindns.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/captaindns.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000" always;

    # Rest der Konfiguration
}

Preload-fähige Konfiguration:

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

Vorsicht bei verschachtelten Blöcken. Nginx wendet add_header nur auf der spezifischsten Ebene an, die ein add_header enthält. Wenn du HSTS auf server-Ebene deklarierst und dann ein anderes add_header in einem location-Block neu deklarierst, verschwindet das HSTS der server-Ebene auf dieser Location. Die Lösung: die HSTS-Direktive in jedem location-Block wiederholen oder more_set_headers aus dem Modul nginx_headers_more verwenden.

Der Lauschblock auf Port 80 muss die 301-Weiterleitung auf HTTPS durchführen:

server {
    listen 80;
    server_name captaindns.com www.captaindns.com;
    return 301 https://$host$request_uri;
}

Füge niemals den HSTS-Header in diesem Port-80-Block hinzu. Die Browser ignorieren ihn (RFC 6797 §8.1), aber das Vorhandensein verfälscht Audits und weist auf eine schlampige Konfiguration hin.

Apache HTTPD

Apache verwaltet HSTS über das Modul mod_headers. Auf Debian und Derivaten aktivierst du es mit sudo a2enmod headers und anschließend sudo systemctl reload apache2. Die Direktive Header always set schreibt den Header bei allen Antworten, einschließlich Fehlern.

Minimalkonfiguration in /etc/apache2/sites-available/captaindns.com.conf oder in einer .htaccess im Site-Stammverzeichnis:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Preload-fähige Konfiguration:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Wie bei Nginx muss der Header ausschließlich im VirtualHost platziert werden, der auf Port 443 lauscht. Der VirtualHost auf Port 80 muss eine Weiterleitung auf HTTPS enthalten, typischerweise über mod_rewrite oder die Direktive Redirect permanent:

<VirtualHost *:80>
    ServerName captaindns.com
    ServerAlias www.captaindns.com
    Redirect permanent / https://captaindns.com/
</VirtualHost>

Die Platzierung in .htaccess funktioniert ebenfalls, was bei Shared Hosting nützlich ist. Es muss jedoch sichergestellt werden, dass die Direktive AllowOverride Headers in der Serverkonfiguration erlaubt.

Cloudflare

Cloudflare bietet eine native HSTS-Verwaltung in seinem Dashboard. Zwei Vorteile: keine Änderung der Serverkonfiguration und Cloudflare liefert den Header bei allen Antworten aus, die das CDN passieren, einschließlich der edge-seitig verwalteten Fehlerseiten.

Um HSTS auf Cloudflare zu aktivieren:

Melde dich am Cloudflare-Dashboard an und wähle die Domain aus.
Gehe zu SSL/TLS und dann Edge Certificates.
Scrolle bis HTTP Strict Transport Security (HSTS) und klicke auf Enable HSTS.
Lies den Hinweis, hake "I understand" an und klicke auf Next.
Konfiguriere die Optionen:
- Max Age: wähle mindestens 12 Monate (18 oder 24 Monate für Preload).
- Apply HSTS policy to subdomains: aktiviert includeSubDomains.
- Preload: aktiviert die Direktive preload.
- No-Sniff Header: fügt X-Content-Type-Options: nosniff hinzu (empfohlen).
Klicke auf Save.

Cloudflare fügt den Header sofort allen Antworten hinzu. Prüfe via curl -I https://captaindns.com, dass der Header tatsächlich vorhanden ist.

Achtung: Cloudflare liefert HSTS aus, selbst wenn dein Origin hinter Cloudflare auf HTTP läuft. Das ist eine klassische Falle: Du kannst deine Website preload-fähig machen, obwohl der Origin technisch ungesichert ist. Wenn du eines Tages das CDN wechselst oder auf DNS Only umstellst, landen Besucher auf einem durch HSTS blockierten HTTP-Origin. Bevor du Preload via Cloudflare aktivierst, stelle sicher, dass dein Origin tatsächlich HTTPS verwendet.

AWS CloudFront

CloudFront verwaltet HSTS über die Response Headers Policies, die 2021 eingeführt wurden. Du kannst eine von AWS verwaltete Policy (Managed-SecurityHeadersPolicy) verwenden oder eine benutzerdefinierte Policy für eine feinere Kontrolle erstellen.

Über die AWS-Konsole:

CloudFront → Policies → Response headers → Create response headers policy.
Abschnitt Strict-Transport-Security: aktiviere die Checkbox.
Trage ein:
- Max-age (seconds): 63072000 für Preload, sonst 31536000.
- Include subdomains: anhaken für Preload.
- Preload: anhaken für Preload.
- Override origin: anhaken, damit CloudFront den vom Origin eventuell gesendeten Header überschreibt (empfohlen).
Erstelle die Policy und hänge sie dann im Tab Behaviors an deine CloudFront-Distribution an.

Über Terraform:

resource "aws_cloudfront_response_headers_policy" "security" {
  name = "captaindns-security-headers"

  security_headers_config {
    strict_transport_security {
      access_control_max_age_sec = 63072000
      include_subdomains         = true
      preload                    = true
      override                   = true
    }
  }
}

resource "aws_cloudfront_distribution" "captaindns" {
  # ...
  default_cache_behavior {
    # ...
    response_headers_policy_id = aws_cloudfront_response_headers_policy.security.id
  }
}

Der Vorteil einer Response Headers Policy gegenüber einer CloudFront Function sind die Kosten: kostenlos, keine Abrechnung pro Anfrage.

Caddy

Caddy fällt aus dem Rahmen: Es liefert HSTS bewusst nicht standardmäßig aus. Matt Holt, sein Schöpfer, hält eine automatische Aktivierung für gefährlich für Nutzer, die HTTPS später wieder entfernen möchten.

Die manuelle Aktivierung ist einfach, über die Direktive header im Caddyfile:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=31536000"
    }

    # Rest der Konfiguration
}

Für die Preload-Version:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    }
}

Caddy verwaltet die HTTP-zu-HTTPS-Weiterleitung automatisch und erneuert seine Let's Encrypt-Zertifikate im Hintergrund. Du kannst HSTS daher mit Vertrauen ab Tag 1 aktivieren, weil Caddy die HTTPS-Verfügbarkeit langfristig garantiert.

Bei einem Reverse Proxy ist das Pattern identisch, platziere die Direktive header im Block, der das Frontend bedient:

captaindns.com {
    header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    reverse_proxy localhost:3000
}

HSTS-Preload durchführen

Sobald der HSTS-Header mit den drei Direktiven auf deiner Apex-Domain stabil ist, kannst du die Einreichung in die Preload-Liste vornehmen. Überstürze diesen Schritt nicht: die Entscheidung ist nahezu unumkehrbar.

Checkliste vor der Einreichung

Geh diese Liste durch. Jedes Kästchen muss abgehakt sein.

Alle öffentlichen Subdomains (www, api, mail, blog, shop) liefern HTTPS mit gültigem Zertifikat aus.
Alle internen Subdomains (staging, admin, monitoring, ci) liefern HTTPS aus oder sind nach außen geschlossen.
Die Apex-Domain liefert https:// mit einem Zertifikat aus, dessen SAN den Apex korrekt abdeckt.
Die HTTP-zu-HTTPS-Weiterleitung auf der Apex-Domain gibt einen 301 zurück (keinen 302).
Der HSTS-Header auf dem Apex enthält max-age=31536000 (oder mehr), includeSubDomains und preload.
Die TLS-Kette ist vollständig (kein fehlendes Zwischenzertifikat).
Du hast keine von einem Dritten verwaltete Subdomain, die kein HTTPS unterstützen könnte (z. B. ein altes Blog über HTTP bei einem Legacy-Hoster).
Du hast mindestens 30 Tage mit der finalen Konfiguration gelebt, um Grenzfälle einzufangen.

Lass den automatischen Test auf hstspreload.org laufen. Wenn ein roter Indikator erscheint, korrigiere ihn vor der Einreichung. Typische Fehler: selbstsigniertes Zertifikat auf www, 302-Weiterleitung statt 301, fehlender HSTS-Header in der 301-Antwort des HTTP.

Die Domain einreichen

Sobald der Test grün ist, klicke auf den Submit-Button, gib deine E-Mail-Adresse ein und bestätige. Die Domain wechselt in den Status pending. Innerhalb von 3 bis 4 Wochen wird sie in den Quellcode von Chromium integriert. Innerhalb von 6 bis 12 Wochen ist sie in den stabilen Versionen von Chrome, Firefox, Safari und Edge enthalten.

Du kannst den Status verfolgen:

curl "https://hstspreload.org/api/v2/status?domain=captaindns.com"

Mögliche Status: unknown (unbekannt), pending (in Bearbeitung), preloaded (eingetragen), rejected (abgelehnt, siehe Details).

Die Policy nach der Einreichung pflegen

Behalte den HSTS-Header mit den drei Direktiven dauerhaft bei. Manche Unternehmen entfernen preload nach der Einreichung in dem Glauben, es sei abgeschlossen: das ist ein Fehler. Das durchgängige Vorhandensein der Direktive wird bei den periodischen Audits der Preload-Liste durch das Chromium-Team überprüft, und sein Fehlen kann zur Streichung führen.

Eine Domain austragen (langwieriges Verfahren)

Wenn du deine Domain aus der Preload-Liste entfernen musst:

Gehe zu hstspreload.org/removal/.
Gib die Gründe an (Domainverkauf, Infrastrukturmigration etc.).
Liefere max-age=0 während der Austragsphase auf deiner Domain aus.
Warte 4 bis 12 Wochen für die Integration in Chromium.
Warte weitere 6 bis 12 Monate, bis die Mehrheit der Nutzer ihren Browser aktualisiert hat.

Während dieser Zeit bleibt deine Domain in den meisten Browsern auf HTTPS gezwungen. Plane das Verfahren, bevor du TLS nicht mehr ausliefern kannst.

Häufige Fehler und Anti-Pattern

HSTS aktivieren, ohne die HTTPS-Kette getestet zu haben

Das ist der teuerste Fehler. max-age=31536000 zu aktivieren, bevor validiert wurde, dass alle Endpunkte HTTPS korrekt ausliefern, blockiert die Nutzer für ein Jahr. Beginne immer bei max-age=300 und steigere in Stufen.

`always` in Nginx vergessen

Ohne always wird add_header nur bei 2xx/3xx-Antworten ausgegeben. Auf einer 500- oder 404-Fehlerseite verschwindet der HSTS-Header. Wenn diese Seite die erste ist, die ein neuer Besucher zu sehen bekommt, wird die Policy nicht gespeichert. Ein Angreifer kann diese Lücke ausnutzen.

HSTS über HTTP senden

Technisch ignorieren die Browser den über HTTP empfangenen Header (RFC §8.1). Praktisch zeigt das eine schlampige Konfiguration und stört Audits. Sende HSTS ausschließlich in HTTPS-Blöcken.

Cookies ohne Secure-Attribut

HSTS erzwingt HTTPS auf Browserebene, aber bei einem nicht kompatiblen Browser oder beim allerersten Besuch kann ein Cookie ohne Secure auslaufen. Kombiniere systematisch HSTS und Set-Cookie: ... ; Secure; HttpOnly; SameSite=Lax.

Preload ohne includeSubDomains

Technisch unmöglich: Der Dienst hstspreload.org lehnt jede Einreichung ohne includeSubDomains ab. Manche ausgerollte Konfigurationen aktivieren preload ohne includeSubDomains. Ergebnis: Der Header wird ausgeliefert, aber die Domain wird nie eingetragen, was einen falschen Eindruck von Schutz erzeugt.

Selbstsigniertes Zertifikat auf Staging

Ein Entwickler verbindet sich mit dem von einem selbstsignierten Zertifikat ausgelieferten staging.captaindns.com und besucht dann die Produktion captaindns.com. Nach Aktivierung von HSTS mit includeSubDomains kann der Entwickler nicht mehr auf Staging zugreifen: Der Browser verweigert das selbstsignierte Zertifikat. Lösung: Verwende ein Let's Encrypt-Zertifikat über eine DNS-Challenge oder platziere das Staging auf einer dedizierten Domain, die nicht von der Policy abgedeckt ist.

302-Weiterleitung statt 301

Der Preload-Test verlangt einen 301 "Moved Permanently" für die HTTP-zu-HTTPS-Weiterleitung. Ein 302 "Found" wird abgelehnt. Prüfe mit curl -I http://captaindns.com.

Fehlender HSTS-Header in der Weiterleitungsantwort

Wenn der Browser die erste 301-Antwort über HTTP empfängt, folgt er der Weiterleitung auf HTTPS. Es ist die zweite Antwort (über HTTPS), die HSTS enthalten muss. Manche Konfigurationen platzieren HSTS aus Versehen in der HTTP-Weiterleitung (ohne Wirkung) und vergessen ihn auf dem HTTPS-Ziel.

HSTS in einem HTML-Meta-Tag

HSTS ist ein HTTP-Header, kein HTML-Element. <meta http-equiv="Strict-Transport-Security" content="..."> wird von allen Browsern ignoriert. Sende den Header immer serverseitig.

Nach Infrastrukturwechsel Tests vergessen

Nach Migration auf ein neues CDN, einem Wechsel des Reverse Proxy oder einem Terraform-Update kann der HSTS-Header still verschwinden. Integriere einen automatisierten Test in deine CI/CD, der das Vorhandensein des Headers auf allen Hauptrouten prüft.

Deine HSTS-Konfiguration mit CaptainDNS überprüfen

Bei CaptainDNS bieten wir ein dediziertes Tool, um deine HSTS-Konfiguration in 3 Sekunden zu auditieren, ohne Konto und ohne Anmeldung: der HSTS-Test von CaptainDNS.

Die 5 von CaptainDNS zurückgegebenen HSTS-Bewertungen: F missing, D weak, B good, A preload-ready, A+ preloaded

Das Tool führt drei Prüfungen parallel durch:

Analyse des Headers Strict-Transport-Security: Das Tool fragt die Domain über HTTPS ab, erfasst den Header und parst seine Direktiven. Es erkennt max-age, includeSubDomains, preload sowie zitierte oder fehlerhaft formatierte Werte, die manche Server zurückgeben.
Abfrage der Chrome-Preload-Liste: Über die API von hstspreload.org ruft es den realen Status deiner Domain (unknown, pending, preloaded, rejected) und die Eligibilität für die Einreichung ab.
Berechnung einer handlungsrelevanten Bewertung: Das Ergebnis wird durch eine Bewertung in fünf Stufen zusammengefasst: missing (kein Header), weak (max-age zu niedrig), good (max-age ausreichend), preload-ready (eligibel, aber nicht eingereicht), preloaded (in der Chrome-Liste).

Für jede Bewertung unter preloaded liefert das Tool die fertigen Konfigurations-Snippets zum Einfügen für Nginx, Apache und Cloudflare. Nach dem Deployment des Fixes starte den Test erneut, um den Aufstieg in die nächste Bewertungsstufe zu bestätigen.

Für einen breiteren Blick auf deine Sicherheits-Header (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy) nutze auch unseren Headers Viewer, das die getreue Liste der Header in ihrer Eingangsreihenfolge anzeigt. Um deine HTTP-zu-HTTPS-Weiterleitung zu testen, folgt der Redirect Checker der vollständigen Weiterleitungskette.

Wenn dein Ziel über HSTS hinausgeht und die TLS-Sicherheit deines E-Mail-Bestands abdeckt, sieh dir unseren TLS-Zertifikatsprüfer an, um TLS-Zertifikate zu inspizieren, oder den DANE/TLSA-Check, um eine DANE/TLSA-Verifikation auf deinen Mailservern hinzuzufügen.

FAQ

Was ist HSTS in einem Satz?

HSTS ist ein HTTP-Antwort-Header, der dem Browser anweist, eine Domain während der durch die Direktive max-age festgelegten Dauer ausschließlich über HTTPS zu kontaktieren, was Angriffe neutralisiert, die eine unverschlüsselte Verbindung zu erzwingen versuchen.

Warum zeigt mein Test "HSTS missing" für meine Website?

Drei Ursachen sind möglich: der Header wird gar nicht ausgeliefert, er wird nur über HTTP ausgeliefert (also von den Browsern ignoriert), oder er wird über HTTPS ausgeliefert, aber mit ungültiger Syntax. Verwende ein Tool wie den HSTS-Test von CaptainDNS, um das genaue Problem zu isolieren.

Welchen max-age-Wert wählen?

Für einen vorsichtigen Rollout starte bei max-age=300 (5 Minuten) und steigere dann schrittweise (1 Tag, 1 Woche, 1 Jahr). Für eine stabile Produktion ist max-age=31536000 (1 Jahr) das empfohlene Minimum. Für die Preload-Liste ist max-age=63072000 (2 Jahre) der gängigste Wert. Darüber hinaus gibt es keinen zusätzlichen Sicherheitsgewinn.

Schützt HSTS den allerersten Besuch?

Nein. Ohne Preload-Liste sendet ein Browser, der deine Domain zum ersten Mal besucht, eine HTTP-Anfrage, bevor er den HSTS-Header empfängt. Dieses Bootstrap-Fenster bleibt anfällig für einen Man-in-the-Middle-Angriff. Die Chrome-Preload-Liste löst dieses Problem, indem sie die Liste der bekannten Domains in den Quellcode des Browsers einbettet.

Kann ich HSTS ohne includeSubDomains aktivieren?

Ja, aber der Schutz ist weniger robust. includeSubDomains deckt insbesondere Cookies ab, die auf der Parent-Domain-Ebene definiert sind. Ohne diese Direktive kann ein Angreifer eine HTTP-Anfrage an eine nicht-HTTPS-Subdomain erzwingen, um Cookies abzufangen. Wenn alle deine Subdomains HTTPS ausliefern können, aktiviere sie. Andernfalls akzeptiere einen Teilschutz.

Was passiert, wenn ich HSTS versehentlich deaktiviere?

Auf Nutzerseite nichts Sichtbares, solange die zuvor empfangene Policy nicht abgelaufen ist. Der Browser erzwingt weiter HTTPS bis zum Ende von max-age. Um sauber zu deaktivieren, liefere max-age=0 für die Dauer aus, die deinem alten max-age entspricht (mindestens 1 Jahr in stabiler Produktion), und entferne den Header dann vollständig.

Wie teste ich HSTS lokal, ohne meinen Browser zu verschmutzen?

Verwende eine dedizierte Test-Domain (z. B. eine von der IETF reservierte .test-Domain oder eine von deiner Produktion getrennte Second-Level-Domain) mit einem über DNS-Challenge erhaltenen Let's Encrypt-Zertifikat. Vermeide es, HSTS auf deiner Produktionsdomain von deiner Workstation aus zu testen: Eine Fehlkonfiguration kann dich für die gesamte Dauer von max-age blockieren. In der Entwicklung kannst du auch den HSTS-Cache von Chrome über chrome://net-internals/#hsts, Tab "Delete domain security policies", leeren.

Soll ich HSTS von einer Website entfernen, die kein HTTPS mehr verwendet?

Nein, du kannst HSTS nicht einfach entfernen. Sobald ein Browser die Policy gespeichert hat, verweigert er jede HTTP-Verbindung bis zum Ablauf von max-age. Bevor du eine Website auf HTTP migrierst (was nicht empfohlen wird), musst du max-age=0 über HTTPS während der vorherigen Laufzeit ausliefern und den Ablauf in den Browsern deiner Besucher abwarten.

Ist die Preload-Liste reversibel?

Technisch ja, praktisch nein. Die Austragsprozedur auf hstspreload.org dauert 4 bis 12 Wochen für die Integration in Chromium und dann weitere 6 bis 12 Monate, bis die Mehrheit der Nutzer ihren Browser aktualisiert hat. Manche Nutzer werden den Austrag nie sehen. Bevor du dich für die Preload-Liste einreichst, stelle sicher, dass du HTTPS auf dieser Domain über Jahre hinweg aufrechterhalten kannst.

Ersetzt HSTS die 301-Weiterleitung von HTTP auf HTTPS?

Nein, es ergänzt sie. Die 301-Weiterleitung ist für den allerersten Besuch und für Nutzer notwendig, die den HSTS-Header noch nie erhalten haben. HSTS übernimmt für die nachfolgenden Besuche, indem es die URLs auf Browserseite vor dem Netzwerkversand umwandelt. Die beiden Mechanismen müssen koexistieren.

Wie viele Websites sind 2026 in der Preload-Liste?

Im April 2026 sind etwa 120 000 Domains in der Preload-Liste von Chromium eingetragen. Die Quelldatei umfasst rund 18 MB. Unter diesen Domains finden sich die Mehrheit der großen Tech-Akteure (Google, GitHub, Twitter, Facebook, PayPal), aber nur die Hälfte der 20 größten Websites weltweit. Die Sektoren Finanzwesen, Gesundheit und Verwaltung hinken stark hinterher.

Fazit: HSTS, die unverzichtbare Grundlage jeder HTTPS-Infrastruktur

HSTS ist das fehlende Teil einer robusten HTTPS-Konfiguration. Ohne ihn verlässt die allererste Anfrage jedes Besuchs das Netzwerk im Klartext, und der gesamte restliche Verkehr hängt vom korrekten Ablauf der 301-Weiterleitung ab. Mit ihm übernimmt der Browser die Kontrolle und wandelt jede URL lokal um, noch bevor der DNS-Resolver befragt wird.

Drei Punkte zum Mitnehmen:

Aktiviere HSTS schrittweise. Beginne mit max-age=300, um deine HTTPS-Kette zu validieren, und steigere dann in Stufen über 2 bis 4 Wochen. Überwache TLS-Fehler in jeder Stufe.
Füge includeSubDomains hinzu, sobald deine Subdomains bereit sind. Diese Direktive schließt die Tür für Subdomain-Angriffe und schützt deine Cookies in der Tiefe. Mache eine vollständige Bestandsaufnahme, bevor du sie aktivierst.
Erwäge die Preload-Liste für maximalen Schutz. Sie neutralisiert die Schwachstelle des Bootstrap-MITM, ist aber eine nahezu unumkehrbare Verpflichtung. Reiche erst nach 30 Tagen Stabilität in der Produktion ein.

Um deine HSTS-Konfiguration jetzt zu testen, gehe zum kostenlosen HSTS-Test von CaptainDNS. Das Tool berechnet deine Bewertung, analysiert deine Direktiven, fragt die Chrome-Preload-Liste ab und liefert dir die einsatzfertigen Snippets für Nginx, Apache und Cloudflare. Kein Konto erforderlich, Ergebnis in 3 Sekunden.

Eine Status Page in deinem Branding

Ähnliche Artikel