HSTS für Nginx konfigurieren

Schritt-für-Schritt-Anleitung: HTTP Strict Transport Security auf Nginx einrichten, testen und Preload beantragen — mit fertigen Konfigurationen zum Kopieren.

HSTS prüfen Plattform entdecken

Nginx · Schritt für Schritt

Von Wolf-Agents Security Team · Aktualisiert: 16. März 2026

HSTS auf Nginx

HTTP Strict Transport Security (HSTS) weist Browser an, ausschließlich verschlüsselte Verbindungen zu verwenden — der wirksamste Schutz gegen SSL-Stripping-Angriffe. Nginx unterstützt HSTS nativ über die add_header-Direktive, ohne zusätzliche Module. Die Konfiguration dauert weniger als 5 Minuten.

Diese Anleitung zeigt die vollständige Implementierung in drei Schritten: vom HTTP-zu-HTTPS-Redirect über den HSTS-Header bis zur Preload-Registrierung. HSTS ist mit 15 von 166 Punkten ein wichtiger Faktor im Wolf-Agents Web Security Check.

Ausführliche Einführung in HSTS

1 Schritt 1 von 3

HTTPS-Redirect und HSTS-Header konfigurieren

HSTS setzt eine funktionierende HTTPS-Konfiguration voraus. Richten Sie zuerst den HTTP-zu-HTTPS-Redirect ein, dann setzen Sie den HSTS-Header im HTTPS-Server-Block. Wichtig: add_header mit dem always-Keyword verwenden, damit der Header auch bei Fehlerseiten gesetzt wird.

# HTTP-Server: Redirect zu HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS-Server mit HSTS
server {
    listen 443 ssl;
    http2 on;  # seit nginx 1.25.1 als eigene Direktive
    server_name example.com www.example.com;

    # SSL-Zertifikate
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # TLS-Versionen einschränken (nur TLS 1.2 und 1.3)
    ssl_protocols TLSv1.2 TLSv1.3;

    # HSTS Header (nur über HTTPS)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # ... weitere Konfiguration
}

Warum always?

Ohne das always-Keyword setzt Nginx den Header nur bei erfolgreichen Responses (2xx/3xx). Fehlerseiten (404, 500) erhalten keinen HSTS-Header — Angreifer könnten gezielt Fehlerseiten für Downgrade-Angriffe nutzen.

TLS 1.0/1.1 deaktivieren

HSTS erzwingt HTTPS, aber die Verschlüsselungsqualität hängt von der TLS-Version ab. Erlauben Sie ausschließlich TLS 1.2 und TLS 1.3 mit ssl_protocols TLSv1.2 TLSv1.3.

2 Schritt 2 von 3

Konfiguration testen und verifizieren

Prüfen Sie die Nginx-Konfiguration auf Syntaxfehler und laden Sie sie neu. Anschließend verifizieren Sie den HSTS-Header mit curl und den Browser DevTools.

# 1. Konfiguration prüfen und Nginx neu laden
sudo nginx -t && sudo systemctl reload nginx

# 2. HSTS-Header prüfen
curl -sI https://example.com | grep -i strict

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

Weitere Verifikationsmethoden

Browser DevTools

Öffnen Sie die Developer Tools (F12) → Network-Tab → ersten Request anklicken → Response Headers. Der strict-transport-security-Header muss sichtbar sein.

Chrome HSTS-Internals

Öffnen Sie chrome://net-internals/#hsts und geben Sie Ihre Domain unter „Query HSTS/PKP domain" ein. Zeigt dynamic_sts_domain wenn HSTS aktiv ist.

SSL Labs Server Test

Auf ssllabs.com/ssltest prüft SSL Labs auch HSTS. Bei korrekter Konfiguration zeigt der Test „HSTS: Yes (long duration)" an.

Starten Sie mit einem kurzen max-age=300 (5 Minuten) und erhöhen Sie schrittweise. So können Sie bei Problemen schnell zurücksetzen.

3 Schritt 3 von 3

HSTS Preload beantragen

Nach erfolgreicher HSTS-Konfiguration können Sie Ihre Domain bei der HSTS Preload List registrieren. Browser erzwingen dann HTTPS ab dem allerersten Besuch — ohne dass der HSTS-Header erst empfangen werden muss.

1 Prüfen Sie, dass der HSTS-Header max-age ≥ 31536000, includeSubDomains und preload enthält

2 Stellen Sie sicher, dass alle Subdomains HTTPS unterstützen

3 Besuchen Sie hstspreload.org, geben Sie Ihre Domain ein und bestätigen Sie die Einreichung

Preload ist quasi-permanent. Die Entfernung aus der Liste dauert mehrere Monate. max-age=0 hilft bei preloaded Domains nicht. Nur beantragen, wenn alle Subdomains dauerhaft HTTPS unterstützen.

Auch verfügbar für:

Apache WordPress Next.js Cloudflare Express Caddy

Wie steht Ihre Domain bei HSTS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Wo setze ich den HSTS-Header in Nginx?

Im server-Block, der Port 443 (HTTPS) lauscht. Verwenden Sie die add_header-Direktive mit dem always-Keyword, damit der Header auch bei Fehlerseiten (404, 500) gesetzt wird. Setzen Sie den Header nie im HTTP-Server-Block (Port 80).

Warum brauche ich das always-Keyword?

Ohne always setzt Nginx den Header nur bei erfolgreichen Responses (2xx/3xx). Fehlerseiten erhalten keinen HSTS-Header — das ist ein Sicherheitsrisiko, weil Angreifer gezielt Fehlerseiten für Downgrade-Angriffe nutzen können.

Muss ich Nginx nach der Änderung neu starten?

Ein Reload genügt — nginx -t prüft die Syntax, systemctl reload nginx lädt die Konfiguration ohne Unterbrechung aktiver Verbindungen. Ein vollständiger Neustart (restart) ist nicht nötig.

Was passiert, wenn ich HSTS auf dem HTTP-Server-Block setze?

RFC 6797 schreibt vor, dass Browser HSTS-Header über unverschlüsselte Verbindungen ignorieren müssen. Der Header hätte auf Port 80 keinerlei Wirkung — setzen Sie ihn ausschließlich im HTTPS-Server-Block (Port 443).

Funktioniert HSTS mit Nginx als Reverse Proxy?

Ja. Setzen Sie den HSTS-Header am Edge (im Nginx-Server-Block), nicht am Backend. Wenn Nginx als Reverse Proxy vor einer Anwendung steht, erreicht der Header den Browser über Nginx — unabhängig davon, ob das Backend den Header selbst setzt.

Welche TLS-Versionen sollte ich in Nginx erlauben?

Nur TLS 1.2 und TLS 1.3 (ssl_protocols TLSv1.2 TLSv1.3). TLS 1.0 und 1.1 gelten seit 2020 als unsicher und sind in aktuellen Browsern deaktiviert. HSTS erzwingt HTTPS, aber die Verschlüsselungsqualität hängt von den erlaubten TLS-Versionen ab.