HSTS (HTTP Strict Transport Security) ist ein HTTP-Response-Header, der durch RFC 6797 definiert ist. Er weist den Browser an, die Domain nur über HTTPS zu kontaktieren, für die in der max-age-Direktive festgelegte Dauer. Sobald der Header gespeichert ist, wandelt der Browser jede http://-Anfrage automatisch in https:// um, bevor sie gesendet wird, was Downgrade- und SSL stripping-Angriffe in nicht vertrauenswürdigen Netzwerken verhindert.

HSTS-Test und Preload-Check: kostenloses HTTP-Tool

Warum HSTS testen?

Der HSTS-Header ist eine der wirksamsten HTTPS-Sicherheitsmaßnahmen, wird aber häufig falsch konfiguriert: zu kurze max-age, vergessene includeSubDomains, oder eine für die Preload-List geeignete Domain, die nie eingereicht wurde. Wer seine Konfiguration regelmäßig testet, erkennt diese Lücken, bevor sie ausgenutzt werden.

Drei zentrale Anwendungsfälle:

Sicherheitsaudit vor dem Go-live: prüfen, dass die HTTPS-Kette, die HTTP-zu-HTTPS-Umleitung und der Strict-Transport-Security-Header zusammenpassen, bevor eine neue Domain öffentlich freigegeben wird.
Vorbereitung auf die Preload-List: die vier Anforderungen prüfen (max-age größer oder gleich 31536000, includeSubDomains, preload, HTTP-zu-HTTPS-Umleitung), bevor die Domain auf hstspreload.org eingereicht wird.
Verifizierung nach einer Migration: nach einer Infrastruktur-Änderung (Wechsel zu Cloudflare, Migration auf einen neuen Nginx-Cluster) bestätigen, dass der HSTS-Header weiterhin mit den richtigen Direktiven auf der Apex-Domain und den Subdomains gesendet wird.

So nutzt du den HSTS-Test in 3 Schritten

Schritt 1: Domain eingeben

Tippe die Root-Domain ohne https:// und ohne Pfad (z. B. captaindns.com). Das Tool zielt automatisch auf die HTTPS-Version der Website und folgt der initialen Umleitung, falls vorhanden. Vermeide Subdomains bei der ersten Analyse, außer du willst gezielt einen bestimmten Dienst prüfen (z. B. api.captaindns.com).

Schritt 2: HSTS-Test starten

Klicke auf Testen. CaptainDNS führt drei Aktionen parallel aus: Abfrage des Strict-Transport-Security-Headers, den der Server zurückgibt, Anfrage an die Preload-List von Chrome zur Statusbestätigung und Analyse der Direktiven max-age, includeSubDomains und preload. Das vollständige Ergebnis erscheint in unter 3 Sekunden.

Schritt 3: Empfehlungen umsetzen

Lies dein Rating (missing, weak, good, preload-ready oder preloaded) und die Liste der vorgeschlagenen Fixes. Kopiere das passende Snippet für Nginx, Apache oder Cloudflare zu deinem Stack, deploye es und starte den Test erneut, um den Sprung zur höheren Stufe zu bestätigen. Iteriere so lange, bis du preloaded erreichst, falls die Preload-List dein Ziel ist.

Was ist HSTS?

HSTS (HTTP Strict Transport Security) ist ein HTTP-Response-Header, der 2012 durch RFC 6797 standardisiert wurde. Wenn ein Browser diesen Header über eine gültige HTTPS-Verbindung empfängt, merkt er sich die Domain und lehnt für die festgelegte Dauer jede Klartext-Verbindung zu ihr ab. Die Umwandlung von http:// zu https:// erfolgt lokal im Browser, vor dem ersten Netzwerkpaket, und schließt damit das Zeitfenster für eine Interception bei der ersten Umleitung.

Der Header besteht aus drei Direktiven:

max-age: Dauer in Sekunden, während der der Browser HSTS erzwingt. Empfohlener Wert für stabilen Produktivbetrieb: 31536000 (1 Jahr). Für die Preload-List: mindestens 31536000.
includeSubDomains: erweitert den Schutz auf alle Subdomains (www, api, mail usw.). Pflicht für die Preload-List.
preload: signalisiert die Zustimmung des Eigentümers zur Einreichung der Domain in die Preload-List von Chrome. Ohne diese Direktive lehnt hstspreload.org die Einreichung ab.

Beispiel eines vollständigen Headers:

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

Ohne HSTS sendet ein Nutzer, der captaindns.com in die Adressleiste tippt, zuerst eine HTTP-Anfrage im Klartext. Ein Angreifer im selben Wi-Fi-Netz kann diese Anfrage abfangen und eine manipulierte Version der Website ausliefern (SSL stripping-Angriff). HSTS macht diesen Angriff nach dem ersten legitimen Besuch unmöglich, und die Preload-List macht ihn schon beim ersten Besuch unmöglich, für Domains, die im Browser vorab geladen sind.

Die 5 Stufen erklärt

CaptainDNS vergibt eine Stufe basierend auf den erkannten Direktiven und dem Preload-Status. Hier die Bewertungsskala:

Stufe	Technisches Kriterium	Empfohlene Maßnahme
missing	Kein Strict-Transport-Security-Header zurückgegeben	HSTS auf dem Server aktivieren, mit max-age=300 starten und dann erhöhen
weak	Header vorhanden, aber max-age unter 86400 (1 Tag)	max-age erhöhen, mindestens 604800 (1 Woche) anstreben
good	max-age größer oder gleich 86400, ohne includeSubDomains oder preload	Subdomains prüfen und dann includeSubDomains hinzufügen
preload-ready	max-age größer oder gleich 31536000, includeSubDomains und preload vorhanden, HTTP-zu-HTTPS-Umleitung aktiv	Domain auf hstspreload.org einreichen
preloaded	Domain in der Preload-List von Chrome bestätigt	Konsistenz überwachen (jede Subdomain muss über HTTPS erreichbar bleiben)

Die Stufe preload-ready bedeutet nicht, dass die Domain in der Preload-List ist: Sie zeigt nur, dass sie die technischen Bedingungen erfüllt, um eingereicht zu werden. Die Einreichung selbst läuft über hstspreload.org, und die Aufnahme in Chrome dauert in der Regel 6 bis 12 Wochen.

So korrigierst du deine HSTS-Konfiguration

Hier die einsatzbereiten Snippets für die drei häufigsten Plattformen. Alle aktivieren ein HSTS, das den Anforderungen der Preload-List entspricht.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

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

Das Schlüsselwort always sorgt dafür, dass der Header auch bei Fehlerantworten (4xx, 5xx) gesendet wird. Ohne dieses Schlüsselwort würde eine 404-Seite den HSTS-Header nicht tragen.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Aktiviere das Modul mit a2enmod headers, falls noch nicht geschehen, und lade Apache dann neu.

Cloudflare Workers

addEventListener('fetch', event =&gt; {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

Bei Cloudflare kannst du HSTS auch direkt im Dashboard aktivieren (SSL/TLS, Edge Certificates, HTTP Strict Transport Security), ohne einen Worker zu deployen.

Starte nach jeder Änderung den HSTS-Test erneut, um die Übernahme auf der CDN- oder Reverse-Proxy-Seite zu bestätigen.

Eintragung in die HSTS-Preload-List

Die Preload-List ist eine Liste von Domains, die fest in Chrome verdrahtet ist (und von Firefox, Safari, Edge und Opera übernommen wird). Jede Domain in der Liste wird von den Browsern schon beim allerersten Besuch als HTTPS-only behandelt, ohne dass der HSTS-Header zuvor empfangen werden muss.

Um eine Domain auf hstspreload.org einzureichen, muss sie vier Bedingungen erfüllen:

max-age größer oder gleich 31536000 (1 Jahr).
Direktive includeSubDomains im Header vorhanden.
Direktive preload im Header vorhanden.
HTTP-zu-HTTPS-Umleitung aktiv auf der Apex-Domain und allen Subdomains.

Auch das Zertifikat muss gültig sein (vollständige Kette, nicht selbst signiert, nicht abgelaufen). Sobald die Einreichung akzeptiert ist, dauert die Aufnahme in Chrome im Schnitt 6 bis 12 Wochen, bis die Änderung in einer neuen stabilen Browser-Version ausgeliefert wird.

Warnung zur Unumkehrbarkeit. Die Entfernung einer Domain aus der Preload-List ist technisch möglich (Entfernungsformular auf hstspreload.org), aber sie dauert mehrere Monate und wirkt nur auf zukünftige Versionen von Chrome. Nutzer mit älteren Versionen erzwingen weiterhin HTTPS, jahrelang. Prüfe vor der Einreichung, dass jede Produktions-, Staging- und interne Admin-Subdomain über HTTPS erreichbar ist und dass kurzfristig kein Wechsel auf einen anderen Domainnamen geplant ist.

Konkrete Anwendungsfälle

Vorfall 1: Stufe weak nach einem ANSSI-Audit

Symptom: Ein ANSSI-Audit meldet, dass captaindns.com zwar einen HSTS-Header sendet, der max-age-Wert (3600) aber zu niedrig ist, um echten Schutz zu bieten.

Diagnose: Der HSTS-Test bestätigt das Vorhandensein von Strict-Transport-Security: max-age=3600. Keine Direktive includeSubDomains oder preload. Die zugewiesene Stufe ist weak.

Maßnahme: Die Nginx-Konfiguration auf max-age=31536000; includeSubDomains; preload umstellen, nachdem geprüft wurde, dass alle Subdomains (api, mail, status) über HTTPS antworten. Den Test erneut starten: Die Stufe steigt auf preload-ready.

Vorfall 2: Subdomain nach Aktivierung von includeSubDomains kaputt

Symptom: Nach der Aktivierung von includeSubDomains auf captaindns.com wird das interne Tool metrics.captaindns.com für die Teams unerreichbar. Fehler "ERR_SSL_PROTOCOL_ERROR" in Chrome.

Diagnose: Die Subdomain metrics besitzt nur einen HTTP-Endpoint. Die Direktive includeSubDomains, die in den Browsern der Teams gespeichert ist, erzwingt jetzt HTTPS, aber kein Zertifikat wird auf dieser Subdomain ausgeliefert.

Maßnahme: Dringend ein Let's Encrypt-Zertifikat auf metrics ausrollen oder die Direktive includeSubDomains vorübergehend entfernen und den lokalen HSTS-Cache der Teams leeren (chrome://net-internals/#hsts), bis die Subdomain wieder konform ist.

Vorfall 3: preload-ready Domain nie eingereicht

Symptom: Bei einem internen Sicherheitsaudit zeigt der Test, dass captaindns.com seit über einem Jahr preload-ready ist, aber nicht in der Preload-List von Chrome steht. Neue Besucher bleiben beim allerersten Besuch anfällig für SSL stripping.

Diagnose: Die Server-Konfiguration ist korrekt (max-age=31536000, includeSubDomains, preload, HTTP-zu-HTTPS-Umleitung). Der von Chrome zurückgegebene Preload-Status lautet "Not in preload list".

Maßnahme: Die Domain auf hstspreload.org einreichen. Die Bestätigung verfolgen und dann 6 bis 12 Wochen auf die Verbreitung in der stabilen Chrome-Version warten. Die Entscheidung und ihre Unumkehrbarkeit im internen Sicherheitsregister dokumentieren.

FAQ - Häufig gestellte Fragen

F: Was ist HSTS?

A: HSTS (HTTP Strict Transport Security) ist ein HTTP-Response-Header, der durch RFC 6797 definiert ist. Er weist den Browser an, die Domain nur über HTTPS zu kontaktieren, für die in max-age festgelegte Dauer. Sobald der Header gespeichert ist, wandelt der Browser jede http://-Anfrage in https:// um, bevor sie gesendet wird, was Downgrade- und SSL stripping-Angriffe in nicht vertrauenswürdigen Netzwerken verhindert.

F: Welchen max-age-Wert sollst du für HSTS wählen?

A: Für eine vorsichtige Inbetriebnahme starte mit max-age=300 (5 Minuten), um ohne Risiko zu testen. Sobald die HTTPS-Kette validiert ist, steigere schrittweise auf 86400 (1 Tag), dann 604800 (1 Woche). Für die Preload-List ist der Mindestwert 31536000 (1 Jahr), was auch der empfohlene Wert für stabilen Produktivbetrieb ist. Ein höherer Wert bringt keinen zusätzlichen Gewinn.

F: Ist HSTS-Preload reversibel?

A: Ja, aber in der Praxis sehr langsam. Du kannst die Entfernung über hstspreload.org beantragen, aber der Vorgang dauert mehrere Monate und wirkt nur auf zukünftige Versionen von Chrome. Nutzer mit älteren Versionen erzwingen weiterhin HTTPS, jahrelang. Stelle vor der Einreichung sicher, dass alle Ressourcen, einschließlich interner Subdomains, über HTTPS erreichbar sind.

F: Funktioniert HSTS ohne HTTPS?

A: Nein. RFC 6797 verlangt, dass der Strict-Transport-Security-Header ignoriert wird, wenn er über HTTP empfangen wird. Nur Antworten, die über eine gültige TLS-Verbindung ausgeliefert werden, können HSTS im Browser aktivieren. Du musst also zuerst ein gültiges Zertifikat (z. B. Let's Encrypt) ausrollen und den gesamten HTTP-Traffic auf HTTPS umleiten, bevor du den Header sendest.

F: HSTS und HTTPS-Redirect, was ist der Unterschied?

A: Ein 301-Redirect von HTTP auf HTTPS wird vom Server ausgeführt, nachdem die Klartext-Anfrage das Gerät bereits verlassen hat. Ein Angreifer in einer Man-in-the-Middle-Position kann diese erste Anfrage abfangen. HSTS löst dieses Problem: Nach dem ersten Besuch wandelt der Browser http:// selbst in https:// um, bevor irgendetwas ins Netz geht. Der Redirect bleibt für den allerersten Besuch und für Clients nötig, die den Header nie empfangen haben.

F: Sollst du includeSubDomains aktivieren?

A: Ja, sobald alle Subdomains (www, api, mail, admin, intranet usw.) über HTTPS erreichbar sind. Die Direktive includeSubDomains weitet den HSTS-Schutz auf die gesamte Domain aus und ist für die Preload-List Pflicht. Bevor du sie aktivierst, prüfe jede aktive Subdomain: Eine interne Subdomain auf HTTP (z. B. ein Monitoring-Tool) wird unerreichbar, sobald die Browser den Header gespeichert haben.

Ergänzende Tools

Der HSTS-Test kombiniert sich mit anderen CaptainDNS-Tools, um die HTTP-, DNS- und Mail-Sicherheit abzudecken:

Tool	Nutzen
HTTP-Header-Analyse	Vollständige Übersicht der Security-Header (CSP, X-Frame-Options, Permissions-Policy) mit einer Note von A bis F
Redirect Checker	Die HTTP-zu-HTTPS-Umleitungskette prüfen, Pflicht für die Preload-List
DNSSEC Check	Defense in Depth auf der DNS-Seite: HTTPS-Sicherheit durch Signatur der Zone ergänzen
MTA-STS Record Check	HSTS-Pendant für SMTP: TLS auf eingehenden Mail-Strömen erzwingen
Uptime Monitor	Kontinuierliches Monitoring, um eine HSTS-Regression sofort zu erkennen
Page Crawl Checker	Vollständiges On-Page-Audit (HTML, Header, Verhalten), um ein Go-live abzunehmen

Nützliche Ressourcen

Vollständiger HSTS- und Preload-List-Leitfaden von CaptainDNS (Referenzleitfaden zur schrittweisen Aktivierung von Strict-Transport-Security: Direktiven, Konfigurationen für Nginx, Apache, Cloudflare, AWS, Caddy, Preload-Einreichung)
hstspreload.org (offizielles Einreichungsformular für die Preload-List von Chrome)
MDN: Strict-Transport-Security (Referenzdokumentation zum HSTS-Header und seinen Direktiven)
RFC 6797 (Originalspezifikation von HTTP Strict Transport Security)
OWASP HSTS Cheat Sheet (Best Practices für die HSTS-Bereitstellung)
content-security-policy.com (Praxisleitfaden zu HSTS mit Konfigurationsbeispielen)