HSTS erzwingen: Der fehlende Strict-Transport-Security-Header

Läuft eine Website zwar über https, fehlt aber der Strict-Transport-Security-Header, bleibt eine Lücke offen: Der allererste Verbindungsaufbau kann noch über das unverschlüsselte http erfolgen. EverAudit meldet das als Sicherheitsbefund in der Kategorie „Security-Header".

Was ist das Problem?#

Eine https-Seite ohne HSTS-Header verlässt sich darauf, dass Nutzer immer direkt die verschlüsselte Version aufrufen. Tatsächlich tippen viele Menschen weiterhin einfach die Domain ohne Protokoll ein, folgen alten http-Links oder Lesezeichen — der Browser fragt dann zunächst http an, bevor eine Weiterleitung auf https greift.

Der HSTS-Header sieht so aus:

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

max-age=31536000 bedeutet: Der Browser merkt sich ein Jahr lang, dass diese Domain ausschließlich über https erreichbar ist, und wandelt jeden künftigen http-Aufruf selbstständig in https um — noch bevor überhaupt eine Netzwerkverbindung aufgebaut wird.

Warum prüft EverAudit das?#

EverAudit prüft bei jeder über https erreichbaren Seite, ob der Server einen gültigen Strict-Transport-Security-Header mitschickt. Fehlt er, wird das als Prio-1-Befund gemeldet, da es sich um eine grundlegende Transportabsicherung handelt, die unabhängig vom restlichen Sicherheitsniveau der Seite fehlen kann.

Da HSTS in der Regel zentral am Webserver oder CDN gesetzt wird, betrifft ein fehlender Header meist die komplette Domain und nicht nur einzelne Unterseiten — ein einmaliges Nachschärfen der Server-Konfiguration behebt den Befund deshalb typischerweise flächendeckend.

Welche Auswirkung hat das?#

Ohne HSTS bleibt der erste Verbindungsversuch über http eine Angriffsfläche für sogenanntes SSL-Stripping: Befindet sich ein Angreifer im selben Netzwerk — etwa in einem öffentlichen WLAN —, kann er die http-Anfrage abfangen und dem Nutzer dauerhaft eine unverschlüsselte Version der Seite vorspielen, während er selbst mit dem echten Server über https spricht.

Für Besucher bedeutet das: eingegebene Passwörter, Zahlungsdaten oder persönliche Angaben könnten im Klartext mitgelesen werden, ohne dass der Browser eine Warnung anzeigt, weil die gefälschte Seite optisch identisch wirkt. Für den Seitenbetreiber untergräbt das die Wirkung der eigentlich vorhandenen https-Absicherung und wirkt bei einer technischen Prüfung wie eine halb umgesetzte Sicherheitsmaßnahme.

Wie beheben Sie das?#

Den HSTS-Header setzen Sie serverseitig, unabhängig vom verwendeten CMS:

• Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
• Apache: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
• Node/Express: res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains') oder per helmet-Middleware.
• CDN: Viele CDN- und Hosting-Anbieter bieten eine eigene HSTS-Option in den Einstellungen, ohne dass der Ursprungsserver konfiguriert werden muss.

Setzen Sie den Header erst dann, wenn wirklich jede Subdomain und jeder Pfad dauerhaft über https erreichbar ist — ein zu früh gesetzter, langer max-age lässt sich für Browser, die die Domain bereits besucht haben, nicht sofort zurücknehmen. Starten Sie deshalb bei Bedarf mit einem kürzeren max-age (z. B. einigen Tagen), prüfen Sie die Stabilität, und erhöhen Sie den Wert danach schrittweise auf ein Jahr. Optional lässt sich die Domain zusätzlich bei der HSTS-Preload-Liste der großen Browser-Hersteller eintragen, damit der Schutz bereits vor dem allerersten Seitenaufruf greift — das ist ein separater, freiwilliger Schritt und setzt einen stabilen includeSubDomains- sowie preload-Header voraus.

Fazit#

HSTS schließt genau die Lücke, die reines https offenlässt: den ungeschützten ersten Kontakt über http. Der Header ist mit einer einzigen Server-Konfigurationszeile gesetzt, verlangt aber vorher die Gewissheit, dass die gesamte Domain durchgängig verschlüsselt läuft — dann ist er eine der wirkungsvollsten und am einfachsten umsetzbaren Absicherungen überhaupt.