So funktioniert HTTPS: wie SSL/TLS-Zertifikat, HSTS, CSP und Cookies zusammenspielen

1. Die Rolle des Zertifikats verstehen

Baut ein Browser eine HTTPS-Verbindung auf, handelt TLS die Verschlüsselung aus. Dabei prüft der Browser, ob das Zertifikat für den angefragten Hostnamen gilt und über eine Kette vertrauenswürdiger Aussteller bestätigt ist. Das Zertifikat nennt die abgedeckten Namen, seinen Gültigkeitszeitraum und die Angaben, mit denen sich die Vertrauenskette aufbauen lässt. TLS ist der Nachfolger von SSL; im Alltag ist trotzdem meist vom „SSL-Zertifikat“ die Rede.

Legen Sie eine Liste der öffentlichen Namen an: Stammdomain, www und Subdomains für Dienste wie Shop, Kundenportal oder Statusseite. Prüfen Sie jeden vorgesehenen Namen und notieren Sie, welcher Anbieter das jeweilige Zertifikat verwaltet. CDN und Ursprungsserver können getrennte Zertifikate mit eigenen Erneuerungswegen haben. Halten Sie außerdem fest, welches Protokoll eine Verbindung tatsächlich aushandelt, etwa TLS 1.3. Das ist eine konkrete Beobachtung, verrät aber nicht, welche älteren Versionen der Server zusätzlich annimmt. Die OWASP-Empfehlungen zu TLS helfen bei der Auswahl der unterstützten Protokolle und bei der Pflege der Konfiguration.

Die Erneuerung verdient besondere Aufmerksamkeit, weil die Laufzeiten kürzer werden. Öffentlich vertrauenswürdige TLS-Zertifikate, die seit dem 15. März 2026 ausgestellt werden, dürfen höchstens 200 Tage gültig sein. Nach dem Beschluss des CA/Browser Forums sinkt die Grenze ab dem 15. März 2027 auf 100 und ab dem 15. März 2029 auf 47 Tage. Let's Encrypt verschickt seit dem 4. Juni 2025 keine Ablauferinnerungen mehr per E-Mail. Automatische Erneuerung und eine davon unabhängige Ablaufüberwachung gehören deshalb zusammen.

2. Sehen, wie die Schutzschichten zusammenwirken

Diese Maßnahmen ergänzen sich. Das Zertifikat sichert die Verbindung, die Header beschreiben, wie sich eine bestimmte Antwort im Browser verhalten soll. Verschiedene Seiten haben verschiedene Aufgaben: Ein öffentlicher Artikel, eine Kontoseite und ein bewusst einbettbares Widget brauchen jeweils Regeln, die zu ihrer Rolle passen. Header wie CSP oder Frame-Schutz wirken auf Antworten, die der Browser darstellt. Bei einer API, die nur JSON zurückgibt, bringen sie laut OWASP wenig.

3. CSP aus den tatsächlich genutzten Ressourcen aufbauen

Eine Content Security Policy (CSP) legt fest, aus welchen Quellen eine Seite Ressourcen laden darf und welches Verhalten erlaubt ist. Vor allem begrenzt sie die Folgen von Cross-Site-Scripting. Laut MDN ist sie aber kein Ersatz für eine saubere Behandlung von Eingaben. Beginnen Sie mit einer Bestandsaufnahme von Skripten, Bildern, Schriften, Netzwerkverbindungen und Frames. Gehen Sie dafür den gesamten Ablauf durch, damit auch Zahlungs-, Anmelde- und Supportressourcen auf der Liste landen, die erst nach einer Interaktion nachgeladen werden.

Mit dem Header Content-Security-Policy-Report-Only beobachten Sie, wie eine geplante Richtlinie zur tatsächlichen Nutzung passt: Verstöße werden gemeldet, aber nicht blockiert. Werten Sie die Browserkonsole oder den konfigurierten Berichtsempfänger aus, ordnen Sie jede Meldung einer Ressource zu und entscheiden Sie, welche Regel gelten soll. Eine Report-Only-Richtlinie funktioniert nur als HTTP-Header, nicht in einem <meta>-Element. Beide Header lassen sich parallel senden, sodass Sie eine strengere Fassung testen können, während die bisherige Richtlinie weiter gilt. Sind repräsentative Abläufe geprüft, setzen Sie die getestete Richtlinie durch.

Für Skripte empfiehlt MDN eine sogenannte strikte CSP, die einzelne Skripte über Nonces oder Hashes erlaubt, statt lange Listen erlaubter Hosts zu pflegen. Auf 'unsafe-inline' sollten Sie verzichten, weil es laut MDN einen Großteil des Nutzens einer CSP aufhebt. Mit Skripten von Drittanbietern, die ihrerseits weitere Skripte nachladen, ist eine strikte CSP allerdings schwer umzusetzen; planen Sie dafür Zeit ein. Eine dokumentierte Ressourcenliste macht spätere Ergänzungen leichter und erklärt jede einzelne Erlaubnis.

4. HTTPS für den Browser zur festen Regel machen

Mit dem Header Strict-Transport-Security (HSTS) weist eine Website den Browser an, einen Host für einen festgelegten Zeitraum nur noch per HTTPS aufzurufen und spätere HTTP-Aufrufe automatisch umzustellen. Der Browser übernimmt die Regel nur aus einer gültigen HTTPS-Antwort; kommt der Header über unverschlüsseltes HTTP, wird er ignoriert. Die Weiterleitung von HTTP auf HTTPS soll den Header laut MDN deshalb gar nicht enthalten; maßgeblich ist die HTTPS-Antwort. Wählen Sie für max-age (in Sekunden) zunächst eine kurze Dauer, prüfen Sie das Verhalten und verlängern Sie dann schrittweise. Die Preload-Seite hstspreload.org schlägt Stufen von fünf Minuten, einer Woche und einem Monat vor. Als Endwert nennt die OWASP-Übersicht zu HTTP-Headern max-age=63072000, also zwei Jahre.

Bedenken Sie eine Folge: Auf einem HSTS-Host lassen sich Zertifikatsfehler nicht wegklicken. Läuft ein Zertifikat ab, erreichen wiederkehrende Besucher die Website erst wieder, wenn es erneuert ist. Die Option includeSubDomains dehnt die Regel auf alle Subdomains aus. Gleichen Sie diese Entscheidung mit Ihrer Liste der öffentlichen Namen ab und stellen Sie vorher sicher, dass jede Subdomain per HTTPS erreichbar ist. Jede Subdomain sollte den Header trotzdem selbst senden, weil ein Browser die Stammdomain womöglich nie aufruft.

Beim Preloading wird die Domain in eine Liste eingetragen, die Browser fest mitliefern, sodass HTTPS schon beim allerersten Besuch gilt. Das ist eine langfristige Entscheidung: Eine Streichung von der Liste dauert Monate. Die Betreiber von hstspreload.org empfehlen HSTS, Preloading dagegen inzwischen nicht mehr, weil Browser wie Chrome und Safari HTTP-Navigationen ohnehin automatisch auf HTTPS umstellen. Die MDN-Erklärung zu HSTS beschreibt, wie die Optionen zusammenwirken.

5. Cookies und Header an den Ablauf anpassen

Ein Sitzungscookie sorgt dafür, dass der Dienst einen laufenden Besuch wiedererkennt. Drei Attribute bestimmen, wie gut es geschützt ist. Mit Secure sendet der Browser das Cookie nur über HTTPS (localhost ausgenommen); vor JavaScript verbirgt dieses Attribut das Cookie nicht. HttpOnly verhindert, dass Skripte auf der Seite das Cookie lesen, etwa über document.cookie. Der Browser schickt es aber weiterhin mit jeder passenden Anfrage mit, auch mit Anfragen, die ein Skript per fetch() auslöst. HttpOnly erschwert also den Diebstahl von Sitzungscookies über Cross-Site-Scripting (XSS), verhindert XSS selbst aber nicht.

SameSite regelt, ob das Cookie bei websiteübergreifenden Anfragen mitgeschickt wird (Strict, Lax oder None). Weil Browser unterschiedliche Standardwerte verwenden, setzen Sie es ausdrücklich und passend zum Anmelde- und Rücksprungablauf; ein Cookie mit SameSite=None braucht zusätzlich Secure. Die MDN-Referenz zu Set-Cookie beschreibt alle Attribute. Die OWASP-Empfehlungen zum Sitzungsmanagement ordnen SameSite als zusätzliche Schutzschicht gegen CSRF ein, nicht als Ersatz für CSRF-Token.

Weitere Header regeln den Umgang mit Inhalten. X-Content-Type-Options: nosniff lässt den Browser Skripte und Stylesheets blockieren, die mit einem unpassenden MIME-Typ ausgeliefert werden, und hält ihn davon ab, den Typ anderer Antworten zu erraten; der Content-Type muss deshalb überall stimmen. Referrer-Policy legt fest, wie viel von der Adresse der aktuellen Seite im Referer-Header mitgeschickt wird. Ohne Angabe verwenden Browser strict-origin-when-cross-origin; OWASP empfiehlt trotzdem, den Wert ausdrücklich zu senden, weil nicht alle Besucher aktuelle Browser nutzen.

Wo eine Seite eingebettet werden darf, regelt am besten die CSP-Direktive frame-ancestors. Sie wirkt nur als HTTP-Header, nicht im <meta>-Element, und erbt nichts von default-src: Selbst eine Richtlinie mit default-src 'none' erlaubt ohne frame-ancestors das Einbetten durch beliebige Seiten. Als Rückfall für ältere Browser dient X-Frame-Options: DENY oder SAMEORIGIN; der veraltete Wert ALLOW-FROM führt dazu, dass moderne Browser den ganzen Header ignorieren. Den alten Header X-XSS-Protection setzen Sie am besten gar nicht oder ausdrücklich auf 0; OWASP rät von dem veralteten Filter ab. Die OWASP-Übersicht zu HTTP-Headern hilft bei der Auswahl. Halten Sie den Zweck jedes Headers schriftlich fest, damit Anwendung, Proxy und CDN zusammen eine stimmige Richtlinie ausliefern.

6. Das Ergebnis im Browser beobachten

Laden Sie eine normale Seite bei geöffneten Entwicklertools und verfolgen Sie im Netzwerkbereich die Weiterleitungen bis zur endgültigen Antwort. Sehen Sie sich Zertifikat, Header und Cookies an, die tatsächlich ausgeliefert werden. So verbinden Sie die Konfiguration mit dem, was Besucher erleben, und erkennen, welcher Dienst welche Einstellung beisteuert. Wie Sie die Header einzeln mit DevTools oder curl auslesen und mit welchen Werten Sie sicher starten, zeigt der Security Headers Check.

1. Rufen Sie alle öffentlichen Hostnamen per HTTPS auf und einmal ausdrücklich mit http://, um die Weiterleitung zu sehen.
2. Notieren Sie die Zertifikatsdaten und die Richtlinien der endgültigen Antwort.
3. Durchlaufen Sie Anmeldung, Passwort-Wiederherstellung, eingebettete Zahlung und Rücksprünge von externen Diensten.
4. Werten Sie Konsolenmeldungen und den gewählten Berichtsempfänger aus.

Prüfen Sie auch Fehlerseiten. Bei nginx sendet add_header ohne den Zusatz always die Header nur für bestimmte Statuscodes, sodass etwa eine 404-Seite ohne Security-Header ausgeliefert werden kann. Führen Sie ein datiertes Konfigurationsprotokoll und vermerken Sie, wer welche Schicht verwaltet. Ändern sich Hosting oder eine Integration, prüfen Sie das gewünschte Verhalten mit demselben Ablauf. Halten Sie die vorherige Konfiguration griffbereit, damit Sie eine Änderung schnell zurücknehmen können. Die so entstandene Checkliste hilft später allen, die die Website betreuen.

Um die Header einer Website gleich jetzt zu prüfen, nutzen Sie den kostenlosen Security Headers Checker.

7. Die Schutzübersicht nah an der Website halten

Halten Sie öffentliche Namen, Zertifikatsverantwortliche, eingebundene Ressourcen und wichtige Abläufe an einem Ort fest. Einen ersten Blick von außen liefert der kostenlose Snapshot von Sitelemetry: Er führt ohne Anmeldung acht passive Prüfungen an einer öffentlichen Adresse aus, darunter das TLS-Zertifikat und die Security-Header der Startseite, und ist kein Penetrationstest. Der Leitfaden zur Website-Sicherheit zeigt, wie diese Schichten mit Konten, Berechtigungen und der laufenden Pflege zusammenhängen.