Was ist HSTS? HTTP Strict Transport Security erklärt
HSTS weist den Browser an, Ihre Website ausschließlich über HTTPS zu laden – keine Downgrades, kein Wegklicken von Zertifikatsfehlern. So funktioniert es, so aktivieren Sie es unter nginx, Apache, IIS und Cloudflare – und so nutzen Sie Preload sicher.
Führen Sie dieselbe Prüfung jetzt durch — kostenlos
Geben Sie Ihre Domain ein und erhalten Sie ein 9-Punkte-Audit — DNS, SPF/DKIM/DMARC, SSL, Sicherheitsheader, Dark-Web-Exposition — in 60 Sekunden.
Keine Registrierung · <60s · DSGVO/EU-Verarbeitung
Ihre Website leitet vermutlich längst auf HTTPS um, und das Schloss-Symbol erscheint zuverlässig. Doch jedes Mal, wenn ein wiederkehrender Besucher Ihre Adresse ohne https:// eintippt, sendet sein Browser zuerst eine unverschlüsselte HTTP-Anfrage - bevor Ihre Umleitung überhaupt greift. In feindlichen Netzen - Flughafen-WLAN, Hotel-Hotspots, ein kompromittierter Router - ist genau diese eine Anfrage das Einfallstor für Angreifer. HTTP Strict Transport Security (HSTS) schließt es endgültig: ein einziger Response-Header, der dem Browser sagt, mit Ihrer Domain nie wieder unverschlüsseltes HTTP zu sprechen.
Die Lücke ist real: Laut W3Techs (Juli 2026) nutzen 90,1 % aller Websites standardmäßig HTTPS, aber nur 34,1 % senden einen HSTS-Header. Neun von zehn verschlüsseln - kaum jede dritte erzwingt es.
Was ist HSTS?
HSTS (HTTP Strict Transport Security) ist ein Sicherheitsmechanismus, der bereits 2012 in RFC 6797 standardisiert wurde. Er besteht aus einem einzigen HTTP-Response-Header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Empfängt der Browser diesen Header über eine gültige HTTPS-Verbindung, merkt er sich für max-age Sekunden, dass Ihr Host nur per HTTPS erreichbar ist. Ab diesem Moment gilt:
- Jeder
http://-Link, jedes Lesezeichen und jede getippte Adresse Ihrer Domain wird im Browser selbst aufhttps://umgeschrieben (interner 307-Redirect) - bevor auch nur ein Paket das Gerät verlässt. - Zertifikatswarnungen auf Ihrer Website lassen sich nicht mehr wegklicken: kein "Trotzdem fortfahren". Ist das Zertifikat defekt - oder hört jemand die Verbindung ab - verweigert der Browser, Punkt.
Alle großen Browser - Chrome, Edge, Firefox, Safari - unterstützen HSTS seit rund einem Jahrzehnt, auf Desktop und Mobilgeräten.
Warum eine HTTPS-Umleitung allein nicht reicht
Ein klassischer 301-Redirect von HTTP auf HTTPS passiert serverseitig: Der Browser muss die Klartext-HTTP-Anfrage erst senden, und ein Angreifer zwischen Besucher und Server sieht sie, bevor Ihre Umleitung überhaupt antwortet. Genau so funktioniert SSL-Stripping, ein Downgrade-Angriff, den Moxie Marlinspike schon 2009 demonstrierte: Der Angreifer hält das Opfer auf HTTP, spricht selbst HTTPS mit dem echten Server - und liest alles mit.
| Schutz | Nur 301-Redirect | HSTS | HSTS + Preload |
|---|---|---|---|
| Spätere Besuche vor jedem Netzwerkzugriff hochgestuft | ❌ | ✅ | ✅ |
| Allererster Besuch geschützt | ❌ | ❌ | ✅ |
| Zertifikatsfehler nicht wegklickbar | ❌ | ✅ | ✅ |
| Stoppt SSL-Stripping (Downgrade) | ❌ | ✅ nach dem ersten Besuch | ✅ immer |
Was jede Stufe der HTTPS-Erzwingung tatsächlich schützt.
Behalten Sie die Umleitung - Erstbesucher und die Preload-Anforderungen brauchen sie, aber kennen Sie ihre Grenzen.
So funktioniert HSTS, Schritt für Schritt
- Erster Besuch. Der Browser lädt
https://example.com, die Antwort enthält denStrict-Transport-Security-Header, die Richtlinie wird gespeichert. - Jeder weitere Besuch. Jeder Versuch,
http://example.comzu öffnen, wird intern auf HTTPS hochgestuft. Ein Netzwerkmitschnitt würde keinerlei Klartext-Anfrage zeigen. - Der Timer verlängert sich. Jede neue HTTPS-Antwort mit dem Header setzt
max-agezurück - regelmäßige Besucher bleiben dauerhaft geschützt. - Harter Abbruch bei Zertifikatsfehlern. Abgelaufene, selbstsignierte oder manipulierte Zertifikate führen zu einer Fehlerseite ohne Umgehungsmöglichkeit.
Die drei Direktiven
| Direktive | Pflicht? | Funktion | Empfohlener Wert |
|---|---|---|---|
max-age | Ja | Wie lange (in Sekunden) der Browser HTTPS erzwingt | 31536000 (1 Jahr); 63072000 (2 Jahre) ist ebenfalls üblich |
includeSubDomains | Für Preload | Dehnt die Richtlinie auf alle Subdomains aus | Erst wenn alle Subdomains HTTPS ausliefern |
preload | Für Preload | Meldet die Domain für die eingebaute Browser-Liste an | Nach einem stabilen Jahr mit max-age von 1 Jahr |
HSTS auf dem Server aktivieren
Setzen Sie den Header nur in der HTTPS-Konfiguration - über Klartext-HTTP gesendetes HSTS ignorieren Browser laut Spezifikation.
nginx (im server-Block, der auf 443 lauscht):
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Apache (mit aktiviertem mod_headers, im HTTPS-VHost):
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
IIS (web.config):
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
</customHeaders>
</httpProtocol>
Cloudflare: SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Aktivieren; max-age und Subdomain-Optionen wählen Sie im Dashboard.
Prüfen Sie anschließend, ob der Header wirklich ausgeliefert wird: Öffnen Sie Ihre Website, schauen Sie im Netzwerk-Tab der Browser-Entwicklertools nach strict-transport-security in den Response-Headern - oder starten Sie den kostenlosen FortifyNet-Scan, der eine fehlende oder schwache HSTS-Richtlinie markiert.
Schrittweise ausrollen
Eine fehlerhafte HSTS-Richtlinie sperrt Besucher für die gesamte restliche max-age von jeder defekten Nur-HTTP-Ressource aus - aus der Ferne widerrufen lässt sie sich nur, indem Sie max-age=0 über gültiges HTTPS an jeden betroffenen Browser ausliefern. Steigern Sie stattdessen stufenweise:
| Stufe | Header-Wert | Wartezeit |
|---|---|---|
| 1 - Test | max-age=300 | Ein bis zwei Tage |
| 2 - Kurz | max-age=86400 | Eine Woche |
| 3 - Mittel | max-age=2592000 | Ein Monat |
| 4 - Voll | max-age=31536000; includeSubDomains | 3+ Monate |
| 5 - Preload | max-age=31536000; includeSubDomains; preload | Dauerhaft |
HSTS-Preload: die Lücke beim Erstbesuch schließen
Einfaches HSTS ist Trust on First Use: Die allererste Anfrage eines neuen Besuchers bleibt ungeschützt, bis der erste Header eintrifft. Die Preload-Liste löst das - Ihre Domain wird direkt im Browser als HTTPS-only ausgeliefert, sodass selbst Besuch Nummer eins nie Klartext-HTTP berührt.
Die Anmeldung ist kostenlos auf hstspreload.org (die von Chromium gepflegte Liste, die auch Edge, Firefox und Safari nutzen). Die Anforderungen:
- Ein gültiges TLS-Zertifikat.
- HTTP leitet auf demselben Host zu HTTPS um (Port 80 → 443).
- Der HSTS-Header in der HTTPS-Antwort der Basisdomain mit
max-agevon mindestens 31536000 (1 Jahr) plusincludeSubDomainsundpreload. - Jede Subdomain - einschließlich
www- über HTTPS erreichbar.
Behandeln Sie Preload als Einbahnstraße. Die Entfernung aus der Liste braucht Monate, bis sie alle Browser-Versionen erreicht. Aktivieren Sie Preload erst, wenn jede Subdomain - auch interne wie intranet. oder mail. - funktionierendes HTTPS hat.
Verbreitung 2026: HTTPS überall, Erzwingung hinkt nach
HTTPS ist nahezu universell - erzwungen wird es nur von rund einem Drittel der Websites (Quelle: W3Techs, Juli 2026).
Die Browser drängen in dieselbe Richtung. Mit Chrome 147 (April 2026) aktivierte Google "Immer sichere Verbindungen verwenden" für die über 1 Milliarde Nutzer mit erweitertem Safe Browsing, und mit Chrome 154 (Oktober 2026) wird es Standard für alle: Chrome versucht zuerst HTTPS und warnt, bevor öffentliche HTTP-Seiten geladen werden.
Macht das HSTS überflüssig? Nein. Chromes Warnung lässt sich wegklicken; HSTS ist die nicht umgehbare Garantie Ihres eigenen Servers. Es wirkt in jedem Browser unabhängig von dessen Einstellungen, deckt alle Subdomains ab und blockiert das Wegklicken von Zertifikatsfehlern. Beide ergänzen sich.
Häufige HSTS-Fehler
includeSubDomainsblind aktivieren - eine vergessene Nur-HTTP-Subdomain (Intranet, Staging, ein Druckerportal) ist für die gesamtemax-ageunerreichbar.- Den Header über HTTP senden - harmlos, aber wirkungslos; Browser ignorieren ihn.
- Ein
max-agevon wenigen Minuten in Produktion - nahezu kein Schutz, und für Preload unzureichend. - HSTS nach einer Server- oder CDN-Migration vergessen - die Richtlinie läuft still ab, niemand merkt es.
Häufige Fragen
Ersetzt HSTS meine HTTP-zu-HTTPS-Umleitung? Nein. Behalten Sie die Umleitung: Erstbesucher brauchen sie, und die Preload-Liste verlangt sie.
Kann ich HSTS rückgängig machen?
Liefern Sie Strict-Transport-Security: max-age=0 über HTTPS aus - Browser verwerfen die Richtlinie beim nächsten Besuch. Die Entfernung aus der Preload-Liste dauert deutlich länger - Monate, deshalb rollt man vorsichtig aus.
Beeinflusst HSTS die SEO? Nur positiv: Nutzer und Crawler landen garantiert auf einer kanonischen HTTPS-Version Ihrer Website. Ein Ranking-Nachteil existiert nicht.
Woher weiß ich, ob meine Website HSTS sendet?
Prüfen Sie die Response-Header in den Browser-Entwicklertools (Netzwerk-Tab) auf strict-transport-security - oder starten Sie einen kostenlosen FortifyNet-Scan, der HSTS zusammen mit allen weiteren Security-Headern prüft.
Reicht HSTS allein? Es ist einer von mehreren Headern einer gehärteten Website. Kombinieren Sie es mit Content-Security-Policy, X-Content-Type-Options und Co. - siehe unseren vollständigen Security-Header-Leitfaden.
Prüfen Sie Ihr HSTS in 60 Sekunden
Der kostenlose FortifyNet-Scan testet Ihre SSL/TLS-Konfiguration, HSTS und alle weiteren Security-Header, DNS und E-Mail-Authentifizierung sowie Ihre Exponierung im Dark Web - in etwa einer Minute, ohne Registrierung. Fehlt HSTS oder ist es falsch konfiguriert, sehen Sie genau, was zu tun ist.
Verwandte Leitfäden
Ihre Domain jetzt prüfen
Führen Sie eine kostenlose Sicherheitsprüfung durch und sehen Sie, ob Ihre Domain die beschriebenen Probleme hat.
