← Zurück zum Glossar
webentwicklung

HSTS

HTTP Strict Transport Security — Response-Header, der den Browser anweist, eine Domain dauerhaft nur über HTTPS zu kontaktieren.

Aktualisiert: 23. Februar 2026

Was ist HSTS?

HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus, der über einen Response-Header kommuniziert wird. Er weist den Browser an, die betreffende Domain für einen definierten Zeitraum ausschließlich über HTTPS zu kontaktieren — auch wenn der Nutzer explizit http:// eintippt, auf einen alten HTTP-Link klickt oder eine Weiterleitung von HTTP auf HTTPS gibt. Der Browser führt den HTTPS-Upgrade intern durch, ohne jemals einen HTTP-Request ans Netz zu schicken.

Ohne HSTS ist die erste Anfrage an http://example.com unverschlüsselt — anfällig für SSL-Stripping-Angriffe, bei denen ein Man-in-the-Middle die HTTP-zu-HTTPS-Weiterleitung abfängt und beide Parteien glauben lässt, HTTPS sei aktiv.

Kurzprofil HSTS

Kurzprofil

  • Typ: HTTP-Response-Header
  • Header: Strict-Transport-Security
  • Spezifikation: RFC 6797
  • Eingeführt: 2012
  • TOFU-Modell: Trust on First Use — der erste Besuch muss über HTTPS erfolgen
  • Relevanz für WordPress/Web: Hoch — empfohlen für alle Produktionsseiten

Wie funktioniert HSTS?

Der Server sendet beim ersten Besuch (zwingend über HTTPS) den Header:

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

Die Parameter:

  • max-age: Wie lange (in Sekunden) der Browser die Policy anwendet. 31536000 = 1 Jahr. Bei jedem HTTPS-Besuch wird die Uhr neu gestartet.
  • includeSubDomains: Alle Subdomains werden ebenfalls unter HSTS gestellt. Achtung: Wenn auch nur eine Subdomain kein HTTPS hat, ist sie danach unerreichbar.
  • preload: Signalisiert die Bereitschaft, in die Browser-eigene HSTS-Preload-Liste aufgenommen zu werden (Opt-in unter hstspreload.org ). Eingetragene Domains werden von Chrome, Firefox, Safari ohne jemals eine HTTP-Anfrage zu sehen direkt über HTTPS angesprochen.

Das TOFU-Problem (Trust on First Use): Der erste Besuch einer noch nicht gecachten Domain kann über HTTP erfolgen. HSTS schützt erst ab dem zweiten Besuch — es sei denn, die Domain ist in der Preload-Liste.

HSTS in der Praxis

Für WordPress-Setups mit Nginx oder Traefik wird HSTS am besten auf Reverse-Proxy-Ebene gesetzt:

# Nginx
server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

# Traefik Middleware
http:
  middlewares:
    hsts-header:
      headers:
        stsSeconds: 31536000
        stsIncludeSubdomains: true
        stsPreload: true

Wichtige Vorsicht beim Rollout: Ein zu früh gesetztes max-age mit includeSubDomains kann Subdomains ohne HTTPS für Wochen oder Monate unerreichbar machen. Empfohlene Vorgehensweise:

  1. Erst mit max-age=300 (5 Minuten) testen
  2. Auf alle Subdomains HTTPS ausweiten
  3. max-age schrittweise erhöhen (300 → 3600 → 86400 → 31536000)
  4. Erst dann preload hinzufügen
Auf einen Blick

Das Wichtigste

  • HSTS verhindert SSL-Stripping durch Browser-interne Erzwingung von HTTPS
  • Gilt nur für Domains, die bereits HTTPS ausliefern
  • includeSubDomains auch für Subdomains setzen — aber erst wenn alle über HTTPS erreichbar sind
  • preload + Eintrag bei hstspreload.org eliminiert das TOFU-Problem
  • Zu groß gewähltes max-age kann bei HTTPS-Problemen die Seite tagelang unerreichbar machen

Was passiert wenn HSTS falsch konfiguriert ist?

Das größte Risiko: max-age=31536000; includeSubDomains gesetzt, bevor alle Subdomains HTTPS haben. Die Subdomains ohne HTTPS sind dann für Browser, die den HSTS-Cache haben, für ein Jahr nicht erreichbar — weil der Browser den HTTP-Request ins HTTPS umschreibt und das Zertifikat fehlt.

Ebenso kritisch: HSTS auf einer Staging-Domain mit unterschiedlichen Zertifikaten oder wechselnden HTTP/HTTPS-Setups. Dort lieber kein HSTS oder kurze max-age-Werte.

Der preload-Eintrag ist schwer rückgängig zu machen: Nach Aufnahme in die Preload-Liste dauert die Entfernung Monate bis Jahre und muss von allen Browser-Herstellern übernommen werden.

Häufige Fragen

Kann ich HSTS über WordPress (PHP) setzen statt über den Webserver? Technisch ja, aber nicht empfohlen. PHP-basierte Header greifen erst nach dem WordPress-Bootstrap. Webserver-Level-Header sind schneller, konsistenter, und gelten auch für statische Dateien. Außerdem: Bei einem PHP-Fatal-Error wird kein HSTS-Header ausgeliefert.

Was macht das HSTS Preload-Register? Die Preload-Listen von Chrome, Firefox, Safari und Edge enthalten Domains, die von vornherein nur über HTTPS angesprochen werden — noch bevor der erste Besuch stattgefunden hat. Eintragen unter hstspreload.org nach Erfüllung der Anforderungen (HTTPS auf allen Subdomains, max-age ≥ 1 Jahr, includeSubDomains, preload-Flag).

Wie lösche ich den HSTS-Cache im Browser für Tests? Chrome: chrome://net-internals/#hsts → Domain eingeben → "Delete domain security policies". Firefox: about:config → Netzwerk-Cache leeren → security.enterprise_roots.enabled anpassen. Alternativ: Private/Inkognito-Fenster für Tests verwenden.

Verwandte Begriffe

COEP · HTTP

start call_