Eine strenge HSTS-Richtlinie verwenden

Unverschlüsselte Protokolle wie HTTP können anfällig für Abhörangriffe sein, bei denen ein Angreifer die übertragenen Inhalte lesen kann. Glücklicherweise kann der Traffic mit Transport Layer Security (TLS) verschlüsselt werden, was es Angreifern deutlich erschwert, diese Daten zu verwenden, falls sie abgefangen werden.

Angreifer können TLS jedoch umgehen, indem sie verschlüsselte Verbindungen zur Verwendung von unverschlüsseltem HTTP zwingen. Um dieses Problem zu beheben, wurde der HTTP Strict Transport Security-Antwortheader (HSTS) eingeführt. Dieser zwingt den Browser des Nutzers, eine Website nur mit TLS aufzurufen und nicht (für eine festgelegte Zeit) auf unverschlüsseltes HTTP umzuschalten.

Gründe für einen Fehler bei der Lighthouse-Prüfung

Bei der Prüfung werden die folgenden Probleme mit dem HSTS-Header gekennzeichnet:

• Wenn kein HSTS-Header gefunden wird.
• Wenn eine der empfohlenen Richtlinien fehlt (max-age, includedSubDomains, preload)
• Wenn die Dauer der max-age-Anweisung weniger als ein Jahr (31.536.000 Sekunden) beträgt.
• Wenn beim Parsen des Headers ein Syntaxfehler auftritt, z. B. eine unbekannte Anweisung.

Eine strenge HSTS-Richtlinie konfigurieren

Die optimale HSTS-Headerkonfiguration sieht so aus:

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

• Die Richtlinie max-age gibt an, wie lange der Browser des Nutzers gezwungen ist, eine Website nur mit TLS aufzurufen (in Sekunden). Danach kann die Website wieder über HTTP aufgerufen werden, wenn die Website keinen HSTS-Header enthält oder vorübergehende Weiterleitungen von HTTP zu HTTPS eingerichtet sind.
• Wenn Sie die includeSubDomains-Richtlinie festlegen, wird der Header auf allen Subdomains der Seiten-URL erzwungen, von der aus der Header ursprünglich gesendet wird. Wenn beispielsweise ein HSTS-Header von google.com gesendet wird, der die Anweisung includeSubDomains enthält, wird der HSTS-Header auch für mail.google.com erzwungen.
• Wenn Sie die preload-Richtlinie festlegen und die Domain an den HSTS-Preload-Dienst senden, wird die Domain in Browser-Binärdateien kompiliert, die die vorab geladene HSTS-Liste verwenden (nicht nur Google Chrome).

Beim Roll-out des HSTS-Headers gibt es einige Risiken. Alle Funktionen, für die eine unverschlüsselte HTTP-Verbindung erforderlich ist, sind für den in der max-age-Richtlinie festgelegten Zeitraum nicht verfügbar. Potenziell sogar noch länger, wenn die preload-Anweisung angewendet wird.

Um die mit der Einführung verbundenen Risiken zu senken, wird ein gestaffelter Ansatz empfohlen:

1. Mit einer kleinen max-age beginnen und nur includeSubDomains hinzufügen (keine preload):

   max-age=3600; includeSubDomains
   

2. Nach einer Wartezeit (z. B. einer Woche) ohne gemeldete Probleme erhöhen Sie den Wert für max-age, z. B. so:

   max-age=604800; includeSubDomains
   

3. Wenn diese anfängliche Phase über einen längeren Zeitraum (z.B. drei Monate) erfolgreich ist, sollten die Website und ihre Subdomains der HSTS-Preload-Liste und die preload-Richtlinie hinzugefügt werden.

   max-age=63072000; includeSubDomains; preload