- HTTP Security Header sind unsichtbare Anweisungen an den Browser und ergänzen das SSL-Zertifikat, ersetzen es aber nicht.
- Sechs Header bilden die Basis, allen voran die Content-Security-Policy als stärkster und zugleich heikelster Schutz.
- Gerade bei WordPress können falsch gesetzte Header das Layout zerlegen oder Funktionen lahmlegen.
- Empfehlung: Header möglichst über den Server setzen, nur im Ausnahmefall per Plugin.
Deine Website läuft, das Schloss-Symbol im Browser ist grün, ein SSL-Zertifikat ist installiert. Alles sicher, oder? Leider nicht ganz. Zwischen einem verschlüsselten Zertifikat und einer wirklich abgesicherten Website liegen ein paar unscheinbare Zeilen, die viele Seiten schlicht vergessen: die HTTP Security Header.
In diesem Beitrag erklären wir verständlich, was diese Header tun, warum sie für jede Unternehmenswebsite zählen und worauf du gerade bei WordPress aufpassen musst, damit der Schutz nicht zur Stolperfalle wird.
Was sind HTTP Security Header überhaupt?
Stell dir vor, jemand ruft deine Website auf. Bevor auch nur ein Bild oder ein Text erscheint, tauschen der Server deiner Website und der Browser des Besuchers ein paar Informationen aus. In diesem kurzen Moment kann dein Server dem Browser klare Anweisungen mitgeben: Lade diese Seite nur verschlüsselt, führe keine fremden Skripte aus, lass dich nicht in fremde Seiten einbetten.
Genau das sind Security Header. Unsichtbare Spielregeln, die dein Server dem Browser vorgibt, bevor die Seite geladen wird. Der Besucher merkt davon nichts. Angreifer schon.
Security Header sind Teil der HTTP-Response, also der Antwort des Servers auf jede Anfrage. Sie stehen im Kopfbereich (Header) noch vor dem eigentlichen Inhalt (Body). Genau deshalb greifen sie, bevor schädlicher Code im Browser aktiv werden kann.
Die wichtigsten Header im Überblick
| Header | Was er tut | Wovor er schützt |
|---|---|---|
| Strict-Transport-Security (HSTS) | Zwingt den Browser, die Seite künftig nur über HTTPS zu laden, selbst wenn jemand „http://“ eintippt | Umleitung auf eine unverschlüsselte Verbindung, bei der Daten mitgelesen werden können |
| X-Content-Type-Options | Verbietet dem Browser, den Dateityp zu erraten. Er nimmt strikt den vom Server gemeldeten Typ | Angriffe, bei denen ein als Bild getarntes Skript doch als Programmcode ausgeführt wird |
| X-Frame-Options | Erlaubt das Einbetten der Seite in einen Rahmen nur auf der eigenen Domain | Clickjacking, bei dem deine Seite unsichtbar über eine fremde gelegt wird, um Klicks abzufangen |
| Referrer-Policy | Gibt beim Klick auf externe Links nur deine Domain weiter, nicht die komplette Adresse | Datenlecks über interne Adressen oder Suchbegriffe in der Linkadresse |
| Permissions-Policy | Schaltet Browser-Funktionen ab, die die Seite nicht braucht, etwa Kamera, Mikrofon oder Standort | Missbrauch durch eingeschleusten Code, der heimlich Kamera oder Standort aktiviert |
| Content-Security-Policy (CSP) | Eine Positivliste: legt exakt fest, von welchen Quellen Skripte, Schriften und Bilder geladen werden dürfen | Code-Injection und Cross-Site-Scripting, der stärkste Schutz und zugleich der heikelste |
Den aktuellen Stand prüfst du kostenlos auf securityheaders.com oder mit dem Mozilla Observatory. Beide vergeben eine Note von A+ bis F. Viele Unternehmensseiten landen ohne Nacharbeit bei C oder schlechter, obwohl ein SSL-Zertifikat vorhanden ist. Die gute Nachricht: Mit den richtigen Headern ist A oder A+ realistisch erreichbar.
Risiken und Nebenwirkungen, besonders bei WordPress
So nützlich diese Header sind, sie sind kein Schalter, den man einmal umlegt und vergisst. Falsch gesetzt sperren sie nicht den Angreifer aus, sondern deine eigene Website. Gerade WordPress ist hier empfindlich, weil Themes, Page-Builder und Plugins ständig Inhalte aus verschiedenen Quellen nachladen.
- Content-Security-Policy zerlegt das Layout. Elementor, Divi, Google Fonts, eingebettete Karten oder YouTube-Videos und viele Plugins laden Skripte von außen. Eine zu strenge CSP blockiert all das. Die Folge: eine weiße Seite oder ein zerschossenes Design.
- HSTS lässt sich schwer zurücknehmen. Wer die Einstellung zu aggressiv setzt und dabei Subdomains vergisst, die noch kein HTTPS haben, macht diese unter Umständen unerreichbar.
- X-Frame-Options bricht legitime Einbettungen. Buchungssysteme, Zahlungs-Widgets oder Vorschauen im Page-Builder funktionieren plötzlich nicht mehr.
- Permissions-Policy schaltet Funktionen still ab. Wird Standort oder Kamera pauschal gesperrt, sterben Kartenfunktionen oder Buchungstools leise, ohne Fehlermeldung.
- Doppelte Header durch Plugin und Server. Wird ein Header gleichzeitig per Plugin und in der Serverkonfiguration gesetzt, entstehen widersprüchliche Anweisungen.
Die Content-Security-Policy lässt sich zunächst im Modus Content-Security-Policy-Report-Only betreiben. Dabei wird nichts blockiert, der Browser meldet aber, was er blockieren würde. So findest du alle nötigen Quellen, bevor du den Schutz scharf schaltest. Bei HSTS empfiehlt sich ein kurzer max-age-Wert zum Start, der erst nach erfolgreichem Test erhöht wird. Header gehören entweder in die Serverkonfiguration (.htaccess oder nginx) oder in ein Plugin, niemals in beides.
Plugin oder Serverkonfiguration?
Für die Umsetzung in WordPress gibt es zwei Wege, jeder mit einem klaren Trade-off:
- Direkt in der Serverkonfiguration: sauber und performant, aber es braucht Zugriff auf den Server. Ein Fehler kann die Seite kurzzeitig lahmlegen.
- Über ein Plugin: einfach einzurichten, auch ohne Serverzugriff. Dafür entsteht eine zusätzliche Abhängigkeit und die Gefahr von Doppelungen.
Unsere Empfehlung: Der Server hat Vorrang vor dem Plugin. Wenn möglich, setze die Header direkt über den Server. Nur wenn das nicht möglich ist, etwa bei eingeschränktem Hosting ohne Serverzugriff, greife auf ein Plugin zurück.
Häufige Fragen zu HTTP Security Headern
Reicht ein SSL-Zertifikat nicht aus?
Nein. Ein SSL-Zertifikat verschlüsselt die Verbindung zwischen Besucher und Website, das ist die Grundlage. Security Header regeln zusätzlich, wie der Browser mit deiner Seite umgehen darf, und schützen so vor Angriffen, die trotz Verschlüsselung möglich sind.
Verlangsamen Security Header meine Website?
Nein. Header sind nur wenige Zeilen Text in der Serverantwort und haben keinen spürbaren Einfluss auf die Ladezeit. Im Gegenteil: Eine saubere Konfiguration kann unnötige Anfragen sogar reduzieren.
Kann ich Security Header selbst einrichten?
Grundsätzlich ja. Die einfacheren Header sind schnell gesetzt. Heikel wird es bei der Content-Security-Policy, die bei WordPress leicht das Layout zerlegen kann. Hier lohnt sich ein behutsames Vorgehen oder professionelle Unterstützung.
Wie prüfe ich, ob meine Website abgesichert ist?
Einen ersten Eindruck liefern kostenlose Tools wie securityheaders.com. Für ein vollständiges Bild inklusive Cookies, Consent und eingebundener Dienste empfiehlt sich unser professioneller Website-Check, der hier zu finden ist.
Unsicher, wie deine Website aufgestellt ist?
Security Header sind nur ein Baustein einer sicheren Website. Genau hier setzt unser ONEGENT Website-Check an: Wir prüfen deine Seite umfassend auf Security Header, Verschlüsselung, Cookie- und Consent-Einstellungen, eingebundene Dienste und weitere technische sowie rechtliche Punkte. Du bekommst einen verständlichen Bericht mit konkreten Empfehlungen, klar nach Dringlichkeit sortiert, und auf Wunsch setzen wir die Verbesserungen direkt um, ohne dass deine Seite dabei Schaden nimmt.