- HTTPS verschlüsselt den Transportweg zwischen Browser und Server. Ohne es liest jeder mit, der sich in die Verbindung einklinkt.
- Ein gültiges Zertifikat von Let’s Encrypt ist kostenlos und reicht für die meisten Unternehmenswebsites vollständig aus.
- Sicherheitsheader wie HSTS, CSP und X-Content-Type-Options bilden eine zweite Schutzschicht, die ein Zertifikat allein nicht liefert.
- Fünf HTTP-Anweisungen lassen sich in der .htaccess in wenigen Minuten setzen und schließen die häufigsten Angriffspfade.
Das Schloss-Symbol in der Adresszeile kennt fast jeder. Was dahintersteckt, bleibt meistens unklar: SSL und HTTPS verschlüsseln den Transportweg, sagen aber nichts darüber aus, wie sich die Website gegenüber dem Browser verhält. Sicherheitsheader füllen diese Lücke. Was genau dahintersteckt, wo der typische Konfigurationsfehler sitzt und was die fünf wichtigsten Header konkret bewirken, steht in den folgenden Abschnitten.
Was HTTPS wirklich bedeutet
Stellen Sie sich vor, jemand schickt eine Postkarte. Jeder, der die Postkarte in die Hand nimmt, kann mitsehen. Eine Website ohne HTTPS funktioniert so: Formulardaten, Passwörter, Seiteninhalt wandern als Klartext durch das Netz. Wer sich in das WLAN des Cafés oder den Router des Unternehmens einklinkt, liest mit.
HTTPS steckt die Postkarte in einen versiegelten Umschlag. Der Inhalt bleibt privat, auch wenn das Paket an mehreren Stationen vorbeiläuft.
Technisch heißt das Protokoll seit Jahren nicht mehr SSL, sondern TLS (Transport Layer Security). TLS 1.2 und TLS 1.3 sind die aktuellen Versionen. Der Begriff SSL hält sich hartnäckig im Sprachgebrauch, auch auf Hosting-Paketen und in Anleitungen, obwohl das ursprüngliche SSL-Protokoll längst abgelöst wurde. Was Ihr Hosting-Anbieter als SSL-Zertifikat anbietet, ist in Wirklichkeit ein TLS-Zertifikat. Das ist praktisch wichtig, wenn Sie einen Server selbst konfigurieren: TLS 1.0 und TLS 1.1 gelten als unsicher und sind von allen aktuellen Browsern abgeschaltet.
SSL-Zertifikat: Was es ist, wo man es bekommt
Das Zertifikat ist der Schlüssel für die verschlüsselte Verbindung. Ruft ein Browser Ihre Website auf, prüft er, ob der Server ein gültiges Zertifikat besitzt. Stimmt alles, baut er den verschlüsselten Kanal auf. Das Zertifikat stellt eine Zertifizierungsstelle (Certificate Authority, kurz CA) aus. Sie verbürgt sich dafür, dass der Server tatsächlich zu der Domain gehört, für die das Zertifikat ausgestellt ist.
Für die meisten Unternehmenswebsites gilt: ein Domain-Validated-Zertifikat (DV) reicht aus. Die Zertifizierungsstelle prüft nur, ob der Antragsteller die Domain kontrolliert. Das ist der Standard für Unternehmenswebsites und Onlineshops.
Extended-Validation-Zertifikate (EV) prüfen zusätzlich die Identität des Unternehmens. In Browsern sind sie kaum noch sichtbar, seit Chrome und Firefox die grüne Adressleiste abgeschafft haben. Der Mehraufwand lohnt sich für normale Unternehmenswebsites nicht.
Let’s Encrypt: kostenlose Zertifikate für alle
Let’s Encrypt stellt seit 2015 kostenlose DV-Zertifikate aus. Alle großen Browser akzeptieren sie ohne Einschränkung. Heute nutzen weltweit hunderte Millionen Domains Let’s Encrypt (Stand 2024, laut den Jahresberichten der ISRG). Fast alle Hosting-Anbieter aktivieren es auf Knopfdruck oder vollautomatisch.
Ein Let’s Encrypt-Zertifikat ist 90 Tage gültig. Der Gedanke dahinter: kürzere Laufzeiten begrenzen den Schaden, wenn ein Zertifikat kompromittiert wurde. In der Praxis bedeutet das, dass die Verlängerung automatisiert laufen muss. Wer das vergisst oder dessen Hosting-Provider die Automatisierung nicht korrekt eingerichtet hat, bekommt nach 90 Tagen eine Sicherheitswarnung im Browser statt einer Website.
Warum ein Zertifikat allein nicht reicht
Ein gültiges Zertifikat verschlüsselt den Transport. Es sagt aber nichts darüber aus, wie die Website sich gegenüber dem Browser verhält. Drei Probleme bleiben bestehen.
Mixed Content: wenn ein Teil der Seite noch HTTP lädt
Gemischte Inhalte entstehen, wenn eine Seite selbst über HTTPS ausgeliefert wird, aber einzelne Ressourcen wie Bilder, Skripte oder Stylesheets noch über HTTP nachlädt. Das passiert häufig bei alten WordPress-Installationen, die vor der HTTPS-Umstellung erstellt wurden und deren Inhalte noch mit absoluten HTTP-Links gespeichert sind.
Moderne Browser blockieren aktive Mixed-Content-Ressourcen wie JavaScript und CSS. Bilder werden manchmal noch geladen, aber mit einer Warnung. Das Ergebnis ist eine Seite, die teils kaputt wirkt, oder eine Meldung in der Entwicklerkonsole, die verunsichert.
Das erste Verbindungs-Zeitfenster ohne HSTS
Tippt ein Besucher nur den Domainnamen ein, ohne https:// voranzustellen, schickt der Browser zunächst eine unverschlüsselte Anfrage. Der Server antwortet mit einer Weiterleitung auf HTTPS. In diesem kurzen Zeitfenster hat ein Angreifer im gleichen Netzwerk die Möglichkeit, die Anfrage abzufangen, bevor die Weiterleitung greift. Das nennt sich SSL-Strip-Angriff.
Browser-Verhalten ohne Anweisungen
Ein Browser weiß ohne zusätzliche Anweisungen nicht, ob er Ihre Website in einem fremden iFrame einbetten darf oder welchen Quellen er beim Nachladen von Skripten vertrauen soll. Beides sind reale Angriffspfade. Sicherheitsheader liefern diese Anweisungen.
Die wichtigsten Sicherheitsheader erklärt
Sicherheitsheader sind Zeilen im HTTP-Response-Header, die der Webserver mit jeder Antwort mitschickt. Der Browser liest sie und richtet sein Verhalten danach aus. Sie sind in wenigen Minuten gesetzt und kosten keine spürbare Performance.
HSTS (HTTP Strict Transport Security)
http:// eintippt. Der Browser merkt sich diese Anweisung für die gesamte angegebene Dauer.Sobald ein Browser die Anweisung Strict-Transport-Security: max-age=31536000 einmal gesehen hat, ignoriert er künftige HTTP-Anfragen an diese Domain und baut direkt eine HTTPS-Verbindung auf. Das Zeitfenster für SSL-Strip-Angriffe schließt sich. MDN erklärt den vollständigen HSTS-Header inklusive der Parameter includeSubDomains und preload.
Wer includeSubDomains setzt, erklärt alle Subdomains als HTTPS-Only. Das ist sinnvoll, aber setzt voraus, dass wirklich alle Subdomains HTTPS unterstützen. Wer zusätzlich in die HSTS-Preload-Liste eingetragen werden will, braucht preload und muss die Voraussetzungen des Preload-Dienstes erfüllen. Der Eintrag sorgt dafür, dass Browser die HTTPS-Pflicht kennen, noch bevor sie die Website überhaupt das erste Mal aufgerufen haben.
Content Security Policy (CSP)
Die Content Security Policy ist der mächtigste und zugleich aufwändigste Sicherheitsheader. Eine sauber konfigurierte CSP erschwert Cross-Site-Scripting (XSS) erheblich, weil ein Angreifer, der es schafft, Schadcode in die Seite einzuschleusen, diesen Code aus keiner nicht erlaubten Quelle heraus ausführen kann. MDN führt alle CSP-Direktiven auf.
Die Herausforderung liegt in der Abstimmung. Eine zu enge Policy bricht legitime Funktionen, etwa wenn WordPress-Plugins Skripte von externen CDNs laden. Eine zu weite Policy (unsafe-inline, unsafe-eval) bringt kaum Schutz. Für WordPress-Installationen mit mehreren Plugins empfiehlt sich der Einstieg über den Mozilla Observatory: Er zeigt, welche CSP-Lücken die größte Wirkung hätten, und liefert Vorschläge.
X-Frame-Options
Der Wert DENY verbietet jegliche Einbettung in iFrames. SAMEORIGIN erlaubt Einbettung nur aus der eigenen Domain. Für die meisten Websites ist SAMEORIGIN die richtige Wahl, weil manche eingebetteten Tools (Video-Player, Karten) auf derselben Domain laufen. MDN beschreibt X-Frame-Options vollständig. Hinweis: Die modernere Alternative ist die CSP-Direktive frame-ancestors, die flexibler konfigurierbar ist. X-Frame-Options wird von älteren Browsern verstanden und bleibt deshalb als Ergänzung sinnvoll.
X-Content-Type-Options
nosniff verhindert dieser Header, dass Browser Dateien anders interpretieren als der Server es deklariert. Ohne ihn könnte ein Browser eine als Bild getarnte JavaScript-Datei ausführen.MIME-Sniffing ist das Verhalten, bei dem ein Browser den Inhalt einer Datei analysiert und selbst entscheidet, was für ein Dateityp es ist, unabhängig davon, was der Server im Content-Type-Header angibt. Das war ursprünglich als Komfortfunktion gedacht, öffnet aber Angriffspfade. MDN erklärt X-Content-Type-Options mit dem einzigen gültigen Wert nosniff. Dieser Header ist in wenigen Sekunden gesetzt und hat keine bekannten Nebenwirkungen.
Referrer-Policy
Das ist eine DSGVO-relevante Einstellung. Die vollständige URL kann interne Strukturen verraten, zum Beispiel Suchparameter oder Verzeichnisnamen, die für Dritte nicht gedacht sind. Der Wert strict-origin-when-cross-origin sendet bei seiteninternen Links die vollständige URL, bei externen Links nur den Ursprung (also nur https://www.ihre-domain.de ohne Pfad). MDN listet alle Referrer-Policy-Werte auf. Dieser Wert ist seit einigen Jahren der Browser-Standard, es schadet aber nicht, ihn explizit zu setzen.
Permissions-Policy
payment oder fullscreen.Für die meisten Unternehmenswebsites ohne Video-Konferenz-Tool oder Geolokalisierung ist die Empfehlung einfach: alle nicht benötigten Funktionen deaktivieren. MDN beschreibt Permissions-Policy vollständig. Das minimiert den Angriffsbereich eingebetteter Inhalte, etwa wenn ein iFrame aus einer kompromittierten Quelle versucht, auf die Kamera zuzugreifen.
Übersicht: Header, Schutz und Beispielwert
| Header | Schützt vor | Empfohlener Beispielwert |
|---|---|---|
Strict-Transport-Security |
SSL-Strip-Angriffe, unverschlüsselten Erstkontakt | max-age=31536000; includeSubDomains |
Content-Security-Policy |
XSS, unerwünschte externe Ressourcenquellen | default-src 'self'; script-src 'self' (anpassen nötig) |
X-Frame-Options |
Clickjacking über unsichtbare iFrames | SAMEORIGIN |
X-Content-Type-Options |
MIME-Sniffing, getarnte Schadcode-Dateien | nosniff |
Referrer-Policy |
Datenweitergabe an externe Seiten, DSGVO-Risiken | strict-origin-when-cross-origin |
Permissions-Policy |
Unbefugter Zugriff auf Kamera, Mikrofon, Standort | camera=(), microphone=(), geolocation=() |
Profi-Block: Sicherheitsheader in der .htaccess
Auf Apache-Servern, also dem Standard bei den meisten deutschen Shared-Hosting-Anbietern, lassen sich alle Header über die .htaccess im Webroot setzen. Voraussetzung ist, dass mod_headers aktiv ist, was bei fast allen Hostern der Fall ist.
Ein Hinweis zur CSP: Die Zeile ist absichtlich auskommentiert. Eine Content Security Policy, die ohne vorherige Analyse gesetzt wird, bricht fast immer etwas. Der richtige Weg ist der Content-Security-Policy-Report-Only-Modus: Er protokolliert Verstöße, ohne sie zu blockieren. So sehen Sie, welche Quellen Ihre Website tatsächlich nutzt, bevor Sie die Einschränkungen scharf schalten. Das OWASP Secure Headers Project dokumentiert Best Practices für jeden Header mit Begründungen.
Das BSI empfiehlt in der Technischen Richtlinie TR-02102 explizit TLS 1.2 und TLS 1.3 und rät von TLS 1.0, 1.1 und SSL 3.0 ab. Die Header-Konfiguration ergänzt diese Transportebene auf der Anwendungsebene.
Wie dringend ist das wirklich?
Ein fehlender Sicherheitsheader ist nicht automatisch ein kritisches Loch. Scanner und Penetrationstest-Werkzeuge melden fehlende Header reflexhaft, doch der tatsächliche Schweregrad hängt vom Kontext ab. In etablierten Bug-Bounty-Programmen werden Meldungen über rein fehlende Header oft gar nicht erst angenommen, solange niemand einen praktischen Angriff damit zeigt. Für Ihre Website heißt das: Sicherheitsheader sind eine günstige, sinnvolle Härtung, aber kein Grund zur Panik, wenn einer fehlt. Gewichten Sie sie als Teil der Gesamthärtung, nicht als isolierten Notfall.
Praxisbeispiel: Was ein Header-Check aufdeckt
In einem Projekt für einen mittelständischen Dienstleister im Gesundheitsbereich haben wir den Mozilla Observatory-Test zum ersten Mal durchgeführt. Die Website hatte ein gültiges Let’s Encrypt-Zertifikat und eine funktionierende HTTPS-Weiterleitung. Der Observatory-Score: D+. Kein einziger Sicherheitsheader war gesetzt.
Das bedeutete konkret: Jeder externe Anbieter, der einen Script-Tag in die Seite setzen konnte (damals ein veraltetes Google-Analytics-Plugin), hätte theoretisch Schadcode aus beliebigen Quellen nachladen können. X-Frame-Options fehlte ebenfalls, die Seite war für Clickjacking-Angriffe offen. Die Behebung dauerte eine halbe Stunde: .htaccess anpassen, CSP im Report-Only-Modus starten, eine Woche Logs auswerten, dann scharf schalten. Endergebnis: Observatory-Score A.
Für den Kunden hatte das einen konkreten Effekt: Das Sicherheits-Audit des Unternehmensverbands, das kurz danach stattfand, lobte explizit die Header-Konfiguration. Ähnliche Schritte empfehlen wir auch im Ratgeber zu Sicherheits-Plugins für WordPress.
Häufige Fehler im Betrieb
Die meisten Sicherheitsprobleme entstehen nicht durch das Fehlen eines Zertifikats, sondern durch Konfigurationsfehler oder mangelnde Pflege.
Abgelaufene Zertifikate
Let’s Encrypt-Zertifikate sind 90 Tage gültig. Let’s Encrypt sendet Erinnerungsemails, wenn eine Verlängerung aussteht. Aber wer verlässt sich schon auf E-Mails? Die automatische Verlängerung per Certbot oder über den Hosting-Provider ist die einzig zuverlässige Lösung. Fällt das System aus, ohne dass es jemand bemerkt, sieht der nächste Besucher eine Sicherheitswarnung statt der Website. Für diesen Fall helfen regelmäßige Backups, wie sie die WordPress-Backup-Strategie beschreibt.
Falsch konfigurierte Weiterleitungen
Wenn HTTP-Anfragen nicht sauber auf HTTPS landen oder wenn www- und non-www-Version parallel über HTTPS erreichbar sind, entstehen mehrere Probleme gleichzeitig: Suchmaschinen sehen doppelten Inhalt, Rankingsignale werden aufgeteilt, und HSTS greift nicht einheitlich. Die Weiterleitung muss konsequent und als 301 (dauerhaft) laufen.
Veraltete TLS-Versionen
Ein Server, der noch TLS 1.0 oder 1.1 unterstützt, hat faktisch eine kaputte Verschlüsselung für Clients, die diese Versionen nutzen. Aktuelle Browser verweigern TLS 1.0/1.1 bereits, aber ältere Systeme oder APIs greifen noch darauf zurück. SSL Labs zeigt, welche Protokollversionen Ihr Server anbietet.
HSTS ohne vorherige Überprüfung gesetzt
Wer HSTS mit einer langen max-age setzt, bevor alle Subdomains sauber HTTPS unterstützen, sperrt sich selbst aus. Der Browser merkt sich die Anweisung für die gesamte Laufzeit und verweigert dann HTTP-Verbindungen zu jeder Subdomain, auch zu solchen, für die kein Zertifikat existiert. Deshalb: erst prüfen, dann setzen.
Wenn eine Website trotz allem kompromittiert wird, hilft ein klarer Plan: Unser Ratgeber Website gehackt: der Notfallplan führt durch die wichtigsten Schritte.
So prüfen Sie Ihren Stand
Zwei kostenlose Werkzeuge liefern in wenigen Sekunden ein klares Bild.
Mozilla Observatory prüft Sicherheitsheader und HTTPS-Konfiguration und gibt eine Schulnote von A+ bis F. Der Test ist öffentlich einsehbar und wird von Mozilla gepflegt, einer der verlässlichsten Quellen für Websicherheits-Empfehlungen.
SSL Labs von Qualys analysiert die TLS-Konfiguration des Servers tiefer: welche Protokollversionen aktiv sind, welche Cipher Suites angeboten werden und ob bekannte Schwachstellen vorliegen. Bewertung A oder besser ist der Maßstab.
Beide Tests lassen sich kostenlos und ohne Anmeldung nutzen. Eine Domain eingeben, 30 Sekunden warten, Ergebnis lesen. Wenn Sie wissen möchten, was die Zahlen für Ihre Website konkret bedeuten und welche Schritte als nächstes sinnvoll sind, schauen Sie sich unseren Website-Check an. Die DSGVO-konforme Website hat ebenfalls einen Bezug zur Sicherheitskonfiguration, besonders was Referrer-Policy und Datenweitergabe betrifft. Und wer Zugänge zum System selbst absichern will, findet dazu alles im Ratgeber WordPress-Zugänge absichern.
Sofort-Checkliste
- Läuft die Website ausnahmslos über HTTPS, auch bei direkter Eingabe von
http://? - Ist das Zertifikat gültig und läuft die automatische Verlängerung?
- Gibt es Mixed-Content-Warnungen in der Browser-Konsole (F12)?
- Ist der HSTS-Header gesetzt (
Strict-Transport-Security)? - Sind X-Frame-Options, X-Content-Type-Options und Referrer-Policy gesetzt?
- Wurde die CSP zumindest im Report-Only-Modus getestet?
- Sind TLS 1.0 und TLS 1.1 auf dem Server deaktiviert?
- Hat der Mozilla Observatory-Test ein Ergebnis von B oder besser geliefert?
- HTTPS verschlüsselt den Transport, sagt aber nichts über das Verhalten der Website aus. Sicherheitsheader liefern die zweite Schutzschicht.
- Let’s Encrypt-Zertifikate sind kostenlos, von allen Browsern akzeptiert und reichen für die meisten Unternehmenswebsites aus. Die automatische Verlängerung muss eingerichtet sein.
- Fünf Header (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) lassen sich in wenigen Minuten in der .htaccess setzen. Die CSP braucht mehr Analyse und sollte erst im Report-Only-Modus getestet werden.
- Mozilla Observatory und SSL Labs zeigen in Sekunden, wo die eigene Website steht. Ein Score unter B ist ein Signal, das Handlungsbedarf hat.
Häufige Fragen
Was ist der Unterschied zwischen SSL und TLS?
SSL (Secure Sockets Layer) war der ursprüngliche Name des Verschlüsselungsprotokolls. TLS (Transport Layer Security) ist die modernisierte Nachfolgeversion. Aktuell im Einsatz sind TLS 1.2 und TLS 1.3. SSL 2.0, SSL 3.0 sowie TLS 1.0 und 1.1 gelten als unsicher und werden von keinem aktuellen Browser mehr unterstützt. Der Begriff SSL hat sich im Sprachgebrauch festgesetzt, meint heute aber immer TLS.
Muss ich für ein SSL-Zertifikat zahlen?
Nein. Let’s Encrypt stellt kostenlose Zertifikate aus, die alle Browser akzeptieren und die für die meisten Unternehmenswebsites vollständig ausreichen. Viele Hosting-Anbieter aktivieren Let’s Encrypt automatisch. Kostenpflichtige Zertifikate bieten erweiterte Validierungsstufen oder vereinfachte Verwaltung für viele Domains, sind aber kein Sicherheitsgewinn gegenüber einem korrekt eingerichteten Let’s Encrypt-Zertifikat.
Verlangsamen Sicherheitsheader die Website?
Nein, messbar nicht. Sicherheitsheader werden im HTTP-Response-Header mitgesendet und verursachen keinen nennenswerten Mehraufwand. TLS selbst kostet etwas Latenz, die durch HTTP/2 und moderne Protokolle weitgehend ausgeglichen wird. Eine sicher konfigurierte Website ist in der Praxis nicht langsamer als eine unsichere.
Schützt HTTPS vor Hacking oder Malware auf meiner Website?
Nein. HTTPS verschlüsselt den Transportweg zwischen Browser und Server, sagt aber nichts über den Inhalt aus. Wurde Ihre Website kompromittiert und liefert Schadcode aus, geschieht das genauso über eine HTTPS-Verbindung. Schutz vor Einbrüchen bieten regelmäßige Updates, abgesicherte Zugänge und eine saubere Berechtigungsverwaltung. Das Zertifikat schützt den Transportweg, nicht die Website selbst.
Was ist ein SSL-Strip-Angriff und wie verhindert HSTS ihn?
Tippt ein Nutzer nur den Domainnamen ein, schickt der Browser zunächst eine unverschlüsselte HTTP-Anfrage. Ein Angreifer im gleichen Netzwerk kann diese abfangen, bevor der Server auf HTTPS umleitet. HSTS schließt dieses Zeitfenster: Sobald der Browser die HSTS-Anweisung einmal über HTTPS erhalten hat, stellt er künftige Anfragen an diese Domain direkt als HTTPS, ohne den unverschlüsselten Umweg. Die Preload-Liste geht noch einen Schritt weiter: Browser kennen dort eingetragene Domains von Anfang an als HTTPS-Only, sogar beim allerersten Besuch.
Was tun, wenn ein Sicherheitsheader eine WordPress-Funktion bricht?
Das passiert vor allem bei der Content Security Policy. Der richtige Weg: erst den Content-Security-Policy-Report-Only-Header setzen statt des scharfen Content-Security-Policy-Headers. Im Report-Only-Modus protokolliert der Browser Verstöße in der Konsole, blockiert aber nichts. So sehen Sie, welche Quellen die Website tatsächlich nutzt, bevor Sie die Einschränkungen aktivieren. Die anderen Header (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) haben kaum Nebenwirkungen bei normalen WordPress-Installationen.