WordPress-Sicherheit mit HTTP-Security-Header erhöhen (Aktualisiert 2025)

Die Absicherung von Websites gegen Sicherheitsrisiken ist essenziell. HTTP-Security-Header bieten einen wirkungsvollen Schutz vor vielen Angriffen, indem sie klare Anweisungen an den Browser geben, wie bestimmte Inhalte und Skripte gehandhabt werden sollen. In diesem Artikel werden die wichtigsten Header und deren aktuelle Implementierung vorgestellt – inklusive praktischer Beispiele.

Hinweis: Dies ist eine Aktualisierung. Der ursprüngliche Beitrag wurde im März 2021 veröffentlicht.

Warum sind HTTP-Security-Header wichtig?

Ein Webbrowser versucht Ihnen nicht nur so einfach und schnell wie möglich Websites anzuzeigen, sondern diese auch denkbar sicher auszuliefern. Moderne Browser erledigen diesen Job auch grundsätzlich sehr gut, aber es gibt Bereiche, bei denen der Browser nicht allein entscheiden kann, was zu tun ist. So sind iframes an sich eine gute Sache, weil sie ermöglichen, Anwendungen anderer Websites in die eigene Internetpräsenz einzubinden. Diese Funktion wird aber auch gern missbraucht, um zum Beispiel Ihren Besuchern ein Formular anzuzeigen, das wertvolle Zugangsdaten auf einem fremden Server speichert. Stellen Sie sich dieses Szenario bei der Website Ihrer Bank vor!

Und hier kommen die ‚HTTP-Security-Header‘ ins Spiel. Sie bieten Ihnen Einstellungsmöglichkeiten, um sicherheitsrelevante Entscheidungen für Ihre Website zu treffen, die Ihnen Ihr Browser nicht abnehmen kann. Technisch gesprochen bieten sie eine zusätzliche Sicherheitsebene, indem sie Verhaltensweisen einschränken, die der Browser und der Server sonst zulassen würden, sobald Ihre Website aufgerufen wird. Mithilfe der Website Webbkoll können Sie testen, wie es um die Sicherheit Ihrer Website steht.

Aber woher sollen Sie wissen, welche dieser Sicherheitseinstellungen wichtig sind und wo Sie sie vornehmen können? Dazu haben wir diesen Beitrag verfasst. Lesen Sie einfach weiter.

Hinweis: Bitte kopieren Sie nicht einfach die unten angegebenen Beispiele. Das kann zu großen Problemen auf Ihrer Website führen. Lesen Sie den Beitrag bis zum Ende und nehmen dann – Schritt für Schritt – Ihre eigenen Konfigurationen durch.

Was sind HTTP Security-Header?

Wenn Sie eine Website aufrufen, stellt Ihr Browser eine Anfrage an den Webserver, um die notwendigen Dateien und Daten für die Darstellung der Website zu erhalten. Während dieser Kommunikation tauschen Browser und Webserver auch zusätzliche Informationen aus. Beispielsweise teilt der Browser dem Server mit, welches Gerät, Betriebssystem und welcher Browsertyp verwendet wird. Diese Informationen sowie weitere technische Details werden im sogenannten „HTTP-Header“ übertragen. Der HTTP-Header dient dabei in erster Linie der Koordination, um sicherzustellen, dass der Browser die gelieferten Daten korrekt interpretieren kann.

HTTP-Security-Header sind ein spezieller Teil dieser HTTP-Header, die sicherheitsrelevante Details festlegen. Sie geben Anweisungen, wie der Browser mit bestimmten Inhalten umgehen soll, um die Sicherheit der Website und ihrer Nutzer zu gewährleisten. Manche HTTP-Header, die Datenschutz oder Sicherheitsaspekte betreffen, können ebenfalls als HTTP-Security-Header eingeordnet werden.

Da alle modernen Browser diese Header unterstützen, können Sie durch ihre Nutzung die Sicherheit Ihrer WordPress-Website deutlich erhöhen. Richtig implementiert, schützen sie effektiv vor häufigen Angriffen wie Cross-Site-Scripting (XSS) oder Clickjacking und machen Ihre Website widerstandsfähiger gegen potenzielle Bedrohungen.

Die wichtigsten HTTP-Security-Header

Lassen Sie uns in eine Übersicht in die gängigsten sicherheitsrelevanten Header eintauchen. Das dient dazu, die jeweilige Funktionsweise und die mögliche Schutzfunktion zu verstehen. Die Reihenfolge ist frei gewählt.

Content Security Policy (CSP) – Schutz vor Cross-Site-Scripting (XSS)

Die Content Security Policy (CSP) ist einer der leistungsstärksten und flexibelsten HTTP-Security-Header. Mit ihr können Sie genau definieren, welche Ressourcen wie JavaScript, CSS, Bilder und andere Inhalte auf Ihrer Website geladen werden dürfen und von welchen Quellen diese stammen. Die CSP ist ein mächtiges Werkzeug, um Cross-Site-Scripting-Angriffe (XSS) zu verhindern und die Sicherheit Ihrer Website zu erhöhen.

Warum ist die CSP so komplex?

Die Konfiguration der CSP erfordert Sorgfalt, da jede Website unterschiedliche Anforderungen hat. Wenn die CSP zu strikt ist, könnten wichtige Funktionen Ihrer Website blockiert werden, was zu Fehlern führt. Ist sie hingegen zu lax, bietet sie möglicherweise nicht den nötigen Schutz.

Für WordPress-Websites ist dies besonders knifflig, da oft externe Ressourcen wie Google Fonts, Content Delivery Networks (CDNs) oder Plugins verwendet werden. Diese müssen einzeln in die CSP aufgenommen werden, um sicherzustellen, dass die Website weiterhin funktioniert.

Wann sollten Sie eine CSP nutzen?

• Wenn Sie sich vor Cross-Site-Scripting (XSS) schützen möchten.
• Wenn Sie die Kontrolle darüber haben möchten, welche externen Ressourcen Ihre Website laden darf.
• Wenn Sie bereit sind, die CSP sorgfältig zu konfigurieren und zu testen.

Falls Sie sich unsicher sind oder keine Ressourcen für die umfassende Einrichtung der CSP haben, ist es besser, keine CSP zu verwenden, als eine falsch konfigurierte Richtlinie zu implementieren.

Wie funktioniert die CSP?

Die Content Security Policy gibt dem Browser Anweisungen, welche Quellen als vertrauenswürdig gelten und von wo Inhalte geladen werden dürfen. Alles, was nicht explizit erlaubt ist, wird blockiert. Dadurch können selbst dann keine schädlichen Skripte ausgeführt werden, wenn es einem Angreifer gelingt, solche in die Website einzuschleusen.

Beispiele für CSP-Regeln

• Minimale CSP-Richtlinie:

Header Set Content-Security-Policy "frame-ancestors 'self'"

Für einen einfachen Schutz gegen bestimmte Angriffe, ohne komplexe Konfiguration, können Sie die folgende minimale Richtlinie nutzen: Diese Richtlinie stellt sicher, dass Ihre Website nicht in Frames eingebettet werden kann, außer von der eigenen Domain. Das schützt effektiv vor Clickjacking-Angriffen.

• Nur eigene Inhalte laden:

Content-Security-Policy: default-src 'self'

Diese Regel erlaubt ausschließlich Inhalte von der eigenen Website.

• Einschränkung auf vertrauenswürdige Skript-Quellen:

Content-Security-Policy: script-src 'self' https://trusted-scripts.example.com

Damit dürfen Skripte nur von der eigenen Domain oder von einer bestimmten vertrauenswürdigen Quelle geladen werden.

• Verbot von gefährlichen Elementen:

Content-Security-Policy: object-src 'none'

Diese Regel blockiert potenziell gefährliche Elemente wie <object>, <embed> und <applet> komplett.

Erstellung einer individuellen CSP

Wenn Sie eine individuelle CSP erstellen möchten, definieren Sie gezielt, welche Ressourcen von welchen Quellen geladen werden dürfen. Hier ist ein Beispiel:

Header Set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-scripts.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' https://trusted-images.example.com"

Erklärung der Richtlinie:

• default-src ’self‘: Standardmäßig dürfen alle Ressourcen nur von der eigenen Domain geladen werden.

• script-src ’self‘ https://trusted-scripts.example.com: JavaScript darf nur von der eigenen Domain und einer bestimmten vertrauenswürdigen Quelle geladen werden.

• style-src ’self‘ ‚unsafe-inline‘: Styles dürfen nur von der eigenen Domain stammen, erlauben jedoch ausnahmsweise Inline-Styles (mit Vorsicht zu genießen!).

• img-src ’self‘ https://trusted-images.example.com: Bilder dürfen nur von der eigenen Domain und einer definierten externen Quelle geladen werden.

Tools zur Unterstützung

1. CSP is Awesome: Ein hilfreiches Werkzeug, das Sie bei der Erstellung und Anpassung Ihrer CSP unterstützt. Es vermittelt die Komplexität und zeigt, wie Sie eine Richtlinie entwickeln können.
2. CSP Browser Test: Prüfen Sie, ob Ihr Browser die CSP-Einstellungen korrekt unterstützt. Dies ist besonders wichtig, wenn Sie sicherstellen möchten, dass Ihre Richtlinien auch bei älteren Browsern greifen.
3. Report URI: Mit diesem Tool können Sie Berichte über Verstöße gegen Ihre CSP sammeln und Ihre Konfiguration optimieren.

Herausforderungen für WordPress-Websites

WordPress-Websites laden oft Inhalte von Drittanbieter-Servern, wie:

• Google Fonts
• CDNs für JavaScript-Bibliotheken (z. B. jQuery)
• Plugins und Themes, die externe Ressourcen einbinden

Jede dieser Quellen muss manuell in die CSP aufgenommen werden. Fehlt eine Quelle, funktioniert die Website möglicherweise nicht wie erwartet. Der Schlüssel liegt darin, alle externen Ressourcen zu identifizieren und schrittweise in die CSP einzutragen.

Strict-Transport-Security (HSTS) – Erzwingung sicherer Verbindungen und Schutz vor Downgrade-Angriffen

Der Strict-Transport-Security (HSTS)-Header stellt sicher, dass Ihre Website ausschließlich über eine verschlüsselte HTTPS-Verbindung erreichbar ist. Er gehört zu den essenziellen HTTP-Security-Headern, da er nicht nur die Sicherheit der Datenübertragung erhöht, sondern auch Angriffe wie Man-in-the-Middle (MITM) oder Protokoll-Downgrade-Angriffe verhindert.

Was macht der HSTS-Header?

HSTS weist den Browser an, künftig nur die sichere HTTPS-Version Ihrer Website aufzurufen – auch dann, wenn der Benutzer versehentlich eine unsichere HTTP-URL eingibt. Das reduziert das Risiko, dass Angreifer den Datenverkehr abfangen oder manipulieren können.

Ein häufiger Angriff, den HSTS verhindert, ist der Downgrade-Angriff. Dabei wird ein Benutzer gezwungen, eine unsichere HTTP-Verbindung zu verwenden, um sensible Informationen wie Anmeldeinformationen abzufangen. Mit HSTS wird dies unterbunden, da der Browser automatisch auf HTTPS besteht.

HSTS-Header-Beispiel

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

Erklärung der Parameter

• max-age=31536000: Gibt die Gültigkeitsdauer in Sekunden an (hier ein Jahr).
• includeSubDomains: Erzwingt HTTPS auch für alle Subdomains der Website.
• preload: Meldet Ihre Domain für die Aufnahme in die HSTS-Preload-Liste an, die von Browsern verwendet wird. Das bedeutet, dass Ihre Domain von Anfang an nur über HTTPS zugänglich ist, ohne dass ein initialer HTTP-Aufruf erforderlich ist.

Vorteile von HSTS

1. Erhöhte Sicherheit für Benutzer und Daten: Durch die erzwungene Verschlüsselung wird sichergestellt, dass vertrauliche Informationen wie Login-Daten, Zahlungsinformationen oder persönliche Daten nicht unverschlüsselt übertragen werden.
2. Schutz vor Protokoll-Downgrade-Angriffen: Selbst wenn ein Angreifer versucht, den Benutzer auf eine HTTP-Version der Website umzuleiten, blockiert der Browser den Zugriff.
3. Verhinderung von Man-in-the-Middle-Angriffen: Da alle Verbindungen verschlüsselt sind, können Dritte den Datenverkehr nicht abfangen oder manipulieren.

Hinweise

1. Stellen Sie sicher, dass Ihre Website und alle Subdomains vollständig über HTTPS laufen, bevor Sie den includeSubDomains-Parameter aktivieren. Ansonsten könnten unverschlüsselte Subdomains blockiert werden.

2. Der preload-Parameter sollte nur verwendet werden, wenn Sie Ihre Domain in die HSTS-Preload-Liste eintragen möchten. Einmal in dieser Liste, können Änderungen schwer rückgängig gemacht werden.

Test und Verifikation

Nach der Implementierung des Headers sollten Sie überprüfen, ob er korrekt funktioniert. Tools wie Qualys SSL Labs helfen dabei, die HSTS-Konfiguration Ihrer Website zu testen. Dort sehen Sie auch, ob Ihre Website die Sicherheitsrichtlinien korrekt einhält.

X-Content-Type-Options – Schutz vor MIME-Sniffing

 

Der X-Content-Type-Options-Header ist ein einfacher, aber äußerst effektiver Sicherheitsmechanismus, um eine potenzielle Schwachstelle in der Art und Weise zu schließen, wie Webbrowser mit Dateien umgehen. Dieser Header verhindert das sogenannte MIME-Sniffing, bei dem Browser versuchen, den tatsächlichen Inhalt einer Datei zu erraten, anstatt sich auf die vom Server übermittelte Content-Type-Angabe zu verlassen.

Was ist MIME-Sniffing und warum ist es ein Risiko?

MIME-Typen (Multipurpose Internet Mail Extensions) werden verwendet, um den Typ einer Datei zu definieren – etwa text/html für HTML-Dokumente oder image/jpeg für JPEG-Bilder. Wenn ein Server keinen eindeutigen MIME-Typ angibt oder der Browser Zweifel an der Korrektheit der Angabe hat, versuchen manche Browser, den Inhalt der Datei zu „erraten“. Dies nennt man MIME-Sniffing.

Das Problem: Angreifer können Dateien so manipulieren, dass sie trotz eines scheinbar harmlosen MIME-Typs wie text/plain tatsächlich schädlichen Code enthalten. Ein Browser, der MIME-Sniffing durchführt, könnte solche Dateien fälschlicherweise als ausführbare Skripte interpretieren und ausführen.

Beispiele für Angriffe:

• Cross-Site Scripting (XSS): Eine manipulierte Datei wird als ausführbares JavaScript interpretiert.

• Remote Code Execution: Schadcode wird auf dem Client ausgeführt, indem ein manipuliertes MIME-Sniffing erzwungen wird.

Was macht der X-Content-Type-Options-Header?

Der Header X-Content-Type-Options: nosniff weist den Browser an, sich strikt an die vom Server gesendeten MIME-Typen zu halten und keine eigenen Vermutungen anzustellen. Dadurch wird das Risiko von MIME-Sniffing und damit verbundenen Angriffen ausgeschlossen.

Header-Beispiel

X-Content-Type-Options: nosniff

Vorteile der Verwendung

1. Schutz vor XSS-Angriffen: Dateien mit potenziell schädlichem Code werden nicht als ausführbare Skripte interpretiert, wenn der MIME-Typ korrekt gesetzt ist.
2. Verhinderung von MIME-Typ-Manipulation: Der Browser bleibt strikt bei den vom Server definierten Typen und verhindert so das Ausführen von Code, der von Angreifern eingeschleust wurde.
3. Kompatibilität mit modernen Browsern: Alle gängigen Browser unterstützen diesen Header und setzen ihn korrekt um.

Zusätzliche Empfehlungen

• Stellen Sie sicher, dass Ihr Server die richtigen MIME-Typen für alle ausgelieferten Dateien sendet. Ein falscher MIME-Typ kann dazu führen, dass Dateien nicht korrekt verarbeitet werden.

• Kombinieren Sie den X-Content-Type-Options-Header mit anderen Sicherheitsmechanismen wie einer Content Security Policy (CSP), um umfassenden Schutz vor XSS und anderen Angriffen zu gewährleisten.

Referrer-Policy – Kontrolle über die Weitergabe von Referer-Daten

Die Referrer-Policy ist ein HTTP-Header, der steuert, welche Informationen im sogenannten Referer-Header beim Übergang von einer Website zu einer anderen übermittelt werden. Der Referer-Header enthält normalerweise die URL der ursprünglichen Website, von der ein Nutzer kommt, und wird an die Zielwebsite gesendet. Diese Daten können jedoch sensible Informationen enthalten, beispielsweise Suchbegriffe, Session-IDs oder andere persönliche Daten, die Teil der URL sind.

Mit der Referrer-Policy können Sie genau festlegen, welche Informationen weitergegeben werden sollen und unter welchen Umständen dies geschieht. Damit lässt sich der Datenschutz der Nutzer verbessern und die Angriffsfläche für potenzielle Sicherheitsprobleme reduzieren.

Warum ist die Referrer-Policy wichtig?

Ohne Einschränkungen kann der Referer-Header unnötig viele Informationen über Ihre Website und deren Nutzer preisgeben. Dies birgt Risiken wie:

• Datenschutzverletzungen: Persönliche Daten oder Session-IDs könnten ungewollt an Drittanbieter oder externe Links weitergegeben werden.
• Sicherheitsprobleme: Angreifer könnten sensible Informationen aus URLs auslesen, um gezielte Angriffe vorzubereiten.

Die Referrer-Policy ermöglicht Ihnen, diese Risiken zu minimieren, indem sie die Menge und Art der übermittelten Informationen reduziert.

Werte und Optionen der Referrer-Policy

Es gibt verschiedene Konfigurationsoptionen, die Sie je nach Ihren Anforderungen auswählen können:

• no-referrer: Es wird kein Referer-Header gesendet, unabhängig davon, ob der Link sicher (HTTPS) oder unsicher (HTTP) ist.
• no-referrer-when-downgrade (Standard): Der Referer-Header wird gesendet, wenn der Übergang von HTTPS zu HTTPS erfolgt. Bei einem Downgrade auf HTTP wird der Header nicht übermittelt.
• same-origin: Der Referer-Header wird nur für Links innerhalb derselben Domain gesendet.
• origin: Nur die Basis-URL (z. B. https://example.com) wird gesendet, ohne den vollständigen Pfad.
• strict-origin: Der Referer wird nur bei sicheren Übergängen (HTTPS → HTTPS) gesendet; bei unsicheren Übergängen wird er blockiert.
• origin-when-cross-origin: Innerhalb derselben Domain wird der vollständige Referer gesendet; bei externen Links nur die Basis-URL.
• strict-origin-when-cross-origin: Innerhalb derselben Domain wird der vollständige Referer gesendet; bei externen Links nur die Basis-URL, und nur bei sicheren Übergängen.
• unsafe-url: Der vollständige Referer wird immer gesendet, unabhängig vom Übergangstyp (unsicher!).

Beispiel einer sicheren Einstellung

Referrer-Policy: no-referrer-when-downgrade

Erklärung

Diese Option verhindert, dass Referer-Daten an unsichere (HTTP) Links gesendet werden, während sie bei sicheren Übergängen (HTTPS → HTTPS) übermittelt werden.

Empfehlungen

1. Für maximale Privatsphäre: Nutzen Sie no-referrer, wenn Sie vollständig vermeiden möchten, dass Referrer-Daten an Drittanbieter oder externe Links weitergegeben werden.
2. Für eine gute Balance zwischen Datenschutz und Funktionalität: Verwenden Sie no-referrer-when-downgrade oder strict-origin-when-cross-origin, um sicherzustellen, dass nur bei sicheren Verbindungen relevante Informationen übermittelt werden.
3. Vermeiden Sie unsafe-url: Diese Option überträgt den vollständigen Referrer immer und kann potenziell sensible Informationen preisgeben.

Permissions-Policy (früher Feature-Policy) – Einschränkung von Browser-APIs

Die Permissions-Policy, vormals bekannt als Feature-Policy, ist ein HTTP-Header, der die Nutzung bestimmter Funktionen oder APIs im Browser einschränkt oder deaktiviert. Dazu gehören APIs wie Kamera, Mikrofon, Geolocation oder andere Features, die auf Gerätefunktionen zugreifen können. Durch die gezielte Kontrolle dieser Berechtigungen können Sie die Sicherheit Ihrer Website erhöhen und gleichzeitig den Datenschutz der Nutzer verbessern.

Was macht die Permissions-Policy?

Mit der Permissions-Policy legen Sie fest, ob und unter welchen Umständen eine Website oder eine eingebettete Ressource (wie ein <iframe>) auf bestimmte Funktionen des Browsers zugreifen darf. So können Sie beispielsweise verhindern, dass eine Drittanbieter-Website, die in Ihrer Website eingebettet ist, die Kamera oder das Mikrofon eines Nutzers nutzt.

Warum ist die Permissions-Policy wichtig?

1. Verbesserter Datenschutz: Sie minimieren das Risiko, dass sensible Daten wie Standortinformationen oder Audio-/Videoaufnahmen ohne Zustimmung des Nutzers gesammelt werden.
2. Erhöhte Sicherheit: Sie verhindern, dass bösartige oder kompromittierte Inhalte Zugriff auf kritische Gerätefunktionen erhalten.
3. Präzise Kontrolle: Sie können festlegen, welche Funktionen nur Ihrer eigenen Website und nicht externen Ressourcen erlaubt sind.

Wichtige Funktionen und Beispiele

Mit der Permissions-Policy können Sie den Zugriff auf verschiedene Browser-APIs steuern. Hier sind einige häufig genutzte Optionen:

• Geolocation: Verhindert, dass der Standort des Nutzers abgefragt wird.

Permissions-Policy: geolocation=()

• Mikrofon: Verhindert, dass der Browser Zugriff auf das Mikrofon erlaubt.

Permissions-Policy: microphone=()

• Kamera: Blockiert den Zugriff auf die Kamera des Nutzers.

Permissions-Policy: camera=()

• Fullscreen: Beschränkt die Möglichkeit, den Vollbildmodus zu nutzen.

Permissions-Policy: fullscreen=()

• Payment: Kontrolliert den Zugriff auf die Payment Request API.

Permissions-Policy: payment=()

Dieses sind die wichtigsten Befehle. Eine ausführliche Anleitung der Permission-Policy gibt es bei Github.

Erläuterung der Syntax:

• * erlaubt den Zugriff für alle.
• () blockiert den Zugriff vollständig.
• Eine Liste von erlaubten Domains kann spezifisch definiert werden, z. B. self für die eigene Domain:

Permissions-Policy: geolocation=(self), microphone=()

Beispiel einer umfassenden Permissions-Policy

Permissions-Policy: geolocation=(), microphone=(), camera=(), fullscreen=(self)

Erklärung

• geolocation=(), microphone=(), camera=() blockieren den Zugriff auf Geolocation, Mikrofon und Kamera vollständig.
• fullscreen=(self) erlaubt nur der eigenen Domain, den Vollbildmodus zu aktivieren.

Empfehlungen für die Konfiguration

1. Minimieren Sie die Angriffsfläche: Deaktivieren Sie Funktionen, die für Ihre Website nicht erforderlich sind. Wenn Ihre Website beispielsweise keine Standortdaten benötigt, blockieren Sie den Zugriff auf Geolocation.
2. Erlauben Sie nur notwendige Zugriffe: Falls bestimmte Funktionen wie Kamera oder Mikrofon erforderlich sind, erlauben Sie sie nur für die eigene Domain.
3. Testen Sie Ihre Einstellungen: Überprüfen Sie, ob die implementierten Einschränkungen korrekt greifen und keine wichtigen Funktionen der Website beeinträchtigen.

Hinweis

2021 wurde der Begriff interest-cohort=() speziell eingeführt, um Websites die Möglichkeit zu geben, Google’s Federated Learning of Cohorts (FLoC) zu blockieren. FLoC war ein Versuch von Google, eine datenschutzfreundlichere Alternative zu Cookies zu schaffen, indem Nutzer in Kohorten (Gruppen mit ähnlichen Interessen) zusammengefasst werden, anstatt individuelle Nutzerdaten zu tracken.

Beispiel für die Ergänzung in der Permissions-Policy

Permissions-Policy: geolocation=(), microphone=(), interest-cohort=()

Auch wenn FLoC mittlerweile eingestellt wurde, zeigt dies, wie wichtig es ist, auf neue Tracking-Technologien schnell zu reagieren und passende Sicherheitsmaßnahmen zu implementieren. Es verdeutlicht zudem die Flexibilität der Permissions-Policy, um Datenschutzrisiken aktiv zu adressieren.

X-Frame-Options – Schutz vor Clickjacking-Angriffen

Der X-Frame-Options-Header ist ein wichtiger Sicherheitsmechanismus, der verhindert, dass Ihre Website ohne Erlaubnis in einem iFrame oder einem ähnlichen Frame-Element eingebettet wird. Diese Maßnahme schützt vor Clickjacking-Angriffen, bei denen Benutzer dazu gebracht werden, unwissentlich auf versteckte Schaltflächen oder Links zu klicken, die zu schädlichen Aktionen führen.

Was ist Clickjacking?

Beim Clickjacking wird eine vertrauenswürdige Website unsichtbar in einem iFrame eingebettet, der über eine bösartige Website gelegt wird. Der Benutzer glaubt, mit der sichtbaren Website zu interagieren, klickt jedoch tatsächlich auf Elemente der unsichtbaren eingebetteten Website. Dies kann zu einer Vielzahl von Angriffen führen, wie:

• Datendiebstahl: Der Benutzer wird dazu gebracht, seine Anmeldedaten oder andere sensible Informationen einzugeben.
• Unbefugte Aktionen: Der Angreifer kann Benutzeraktionen wie das Ändern von Einstellungen oder das Senden von Geld auslösen.

Der X-Frame-Options-Header blockiert solche Angriffe, indem er dem Browser vorgibt, wie die Website in Frames geladen werden darf.

Optionen des X-Frame-Options-Headers

Es gibt drei mögliche Werte für den Header:

1. DENY: Verhindert vollständig, dass die Website in einem iFrame geladen wird.

X-Frame-Options: DENY

Empfehlung: Verwenden Sie diese Option, wenn Ihre Website keinerlei Einbettung in Frames benötigt.

2. SAMEORIGIN: Erlaubt das Laden der Website in einem iFrame, jedoch nur, wenn die Anfrage von der gleichen Domain stammt.

X-Frame-Options: SAMEORIGIN

Empfehlung: Geeignet für Websites, die Frames intern nutzen, jedoch keine Einbettung durch externe Domains zulassen möchten.

3. ALLOW-FROM <URL>: Erlaubt das Laden der Website in einem iFrame nur von einer bestimmten Domain.

X-Frame-Options: ALLOW-FROM https://trusted-partner.com

Hinweis: Diese Option wird von vielen modernen Browsern nicht mehr unterstützt und ist daher nur eingeschränkt nutzbar.

Beispiel für die Verwendung des Headers

Wenn Sie sicherstellen möchten, dass Ihre Website nur auf der eigenen Domain in einem iFrame geladen werden kann, verwenden Sie:

X-Frame-Options: SAMEORIGIN

Zusätzliche Hinweise

1. Prüfen Sie auf legitime iFrame-Nutzung: Wenn Ihre Website tatsächlich von Partnern oder internen Anwendungen in Frames genutzt werden muss, stellen Sie sicher, dass diese Funktionalität nicht unbeabsichtigt blockiert wird.
2. Ergänzung durch CSP: Für moderneren Schutz können Sie eine Content Security Policy (CSP) verwenden, um iFrame-Richtlinien noch detaillierter zu steuern. Beispiel:

Content-Security-Policy: frame-ancestors 'self'

So testen Sie Ihre HTTP-Security-Header-Einstellungen

Bevor Sie mit der Absicherung Ihrer Website beginnen, sollten Sie zunächst überprüfen, ob Ihr Webhoster möglicherweise bereits Sicherheitsrichtlinien auf Ihrem Server eingerichtet hat. Dies erspart Ihnen möglicherweise zusätzliche Arbeit oder gibt Ihnen einen Überblick über den aktuellen Sicherheitsstatus Ihrer Website.

Das Testen Ihrer HTTP-Security-Header ist zudem ein wichtiger Schritt, um sicherzustellen, dass Ihre Sicherheitsmaßnahmen korrekt funktionieren und keine unerwünschten Auswirkungen auf Ihre Website haben. Neben der technischen Überprüfung mit Tools sollten Sie immer auch manuell sicherstellen, dass Ihre Website optisch und funktional einwandfrei bleibt. Mit einer Kombination aus gründlicher Analyse und Funktionstests können Sie sicher sein, dass Ihre Website sowohl geschützt als auch benutzerfreundlich bleibt.

Tools zur Überprüfung

Hier sind einige empfehlenswerte Online-Tools, mit denen Sie die vorhandenen HTTP-Security-Header Ihrer Website analysieren können:

• SIWECOS: Ein umfassender Sicherheits-Scanner speziell für deutsche Websites, der auch auf Datenschutzbedenken eingeht.
• SecurityHeaders.com: Ein schnelles Analyse-Tool, das Ihre HTTP-Header bewertet und Verbesserungsvorschläge liefert.
• Observatory by Mozilla: Ein Tool von Mozilla, das einen tiefgehenden Sicherheitscheck durchführt und Ihre Website bewertet.

Testen nach der Einrichtung

Nach der Implementierung neuer HTTP-Security-Header ist es wichtig, die Ergebnisse zu überprüfen. Führen Sie erneut Tests mit den genannten Tools durch, um sicherzustellen, dass die Header korrekt gesetzt wurden und die Sicherheit Ihrer Website verbessert wurde.

Funktionstests durchführen

Neben der Analyse der Header sollten Sie Ihre Website gründlich auf mögliche Darstellungs- oder Funktionsfehler prüfen, die durch die neuen Sicherheitsrichtlinien auftreten könnten. Hier sind einige Punkte, auf die Sie achten sollten:

1. Externe Ressourcen:

• Werden Schriften wie Google Fonts oder andere Ressourcen von Drittanbietern korrekt geladen?
• Funktionieren eingebettete Inhalte wie YouTube-Videos oder Karten-Dienste (z. B. Google Maps)?

2. Navigation und Bedienbarkeit:

• Läuft die Hauptnavigation Ihrer Website reibungslos?
• Sind alle Menüs, Links und Buttons wie gewohnt nutzbar?

3. Plugins und Themes:

• Lassen sich Plugins und Themes weiterhin aktualisieren?
• Funktionieren alle Erweiterungen, insbesondere solche, die Inhalte von externen Servern laden?

4. Performance:

• Hat sich die Ladezeit Ihrer Website durch die neuen Sicherheitsmaßnahmen verändert?

Tipps zur Fehlerbehebung

Falls Probleme auftreten, können Sie schrittweise Anpassungen vornehmen:

1. Schrittweise Einführung: Aktivieren Sie die neuen Sicherheitsrichtlinien zunächst in einem Testumfeld oder nutzen Sie den „Report-Only“-Modus (z. B. für die CSP), um Fehler zu erkennen, ohne die Funktionalität der Website zu beeinträchtigen.
2. Detaillierte Berichte: Nutzen Sie die Berichtsfunktion der Content Security Policy, um Verstöße gegen die Richtlinien zu dokumentieren und schrittweise zu korrigieren.
3. Ergänzen fehlender Ressourcen: Falls externe Ressourcen blockiert werden, ergänzen Sie die entsprechenden Domains in Ihrer Konfiguration (z. B. CSP-Quellen).

Wo füge ich meinen HTTP-Security-Header in WordPress ein?

Das Hinzufügen von HTTP-Security-Headern in WordPress kann auf verschiedene Arten erfolgen, abhängig von Ihren Zugriffsrechten und Ihrer bevorzugten Methode. Hier beschränken wir uns auf gängige WordPress-Optionen und vermeiden komplexere Ansätze wie die Konfiguration auf Server-Ebene oder über Meta-Tags im HTML-Code.

Wichtiger Hinweis vorab:

• Sicherungen anlegen: Bevor Sie Änderungen vornehmen, erstellen Sie eine Kopie der betroffenen Dateien und sichern Sie die Datenbank. Dies hilft, unerwartete Probleme schnell zu beheben.
• Individuelle Anpassung: Kopieren Sie nicht einfach die nachfolgenden Beispiele, sondern passen Sie die Einstellungen schrittweise an die Anforderungen Ihrer Website an.

Einfügen über die .htaccess-Datei

Die .htaccess-Datei ist eine Konfigurationsdatei im Hauptverzeichnis Ihrer WordPress-Installation. Sie wird von WordPress automatisch bei der Installation erstellt und eignet sich hervorragend für das Hinzufügen von HTTP-Security-Headern.

Vorgehen

1. Öffnen Sie die .htaccess-Datei im Hauptverzeichnis Ihrer WordPress-Installation mit einem Texteditor oder über einen FTP-Client.
2. Fügen Sie den folgenden Code möglichst weit oben in die Datei ein:

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=15768000; preload"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer"
Header set Permissions-Policy "accelerometer=(), autoplay=(self), camera=(), encrypted-media=(), fullscreen, geolocation=(self), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(self), usb=()"
Header set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

Erklärung

• Diese Header setzen Sicherheitsrichtlinien wie HSTS, Clickjacking-Schutz und Content-Security-Policies.
• Stellen Sie sicher, dass Ihr Server mod_headers unterstützt, um die Header korrekt anzuwenden.

Einfügen über die functions.php

Wenn Sie keinen Zugriff auf die .htaccess-Datei haben, können Sie die Header alternativ in der functions.php Ihres Themes definieren. Es wird empfohlen, diese Änderungen in einem Child-Theme vorzunehmen, um zukünftige Updates Ihres Themes nicht zu gefährden.

Vorgehen

1. Öffnen Sie die functions.php im WordPress-Editor oder einem Texteditor.
2. Fügen Sie den folgenden Code am Ende der Datei ein:

/* HTTP-Security-Header */
if (!empty($_SERVER['HTTPS'])) {
function en_hsts_header($headers) {
$headers["Strict-Transport-Security"] = "max-age=15768000; preload";
$headers["X-Frame-Options"] = "SAMEORIGIN";
$headers["X-Content-Type-Options"] = "nosniff";
$headers["X-XSS-Protection"] = "1; mode=block";
$headers["Permissions-Policy"] = "accelerometer=(), autoplay=(self), camera=(), encrypted-media=(), fullscreen, geolocation=(self), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(self), usb=()";
$headers["Content-Security-Policy"] = "frame-ancestors 'self'";
return $headers;
}
add_filter('wp_headers', 'en_hsts_header');
}

Erklärung

• Der Code überprüft, ob die Website über HTTPS aufgerufen wird, bevor die Header gesetzt werden.
• Alle Sicherheitsrichtlinien werden direkt in den Header integriert.

Einfügen über ein Plug-in

Wenn Sie keine Änderungen an den Dateien vornehmen möchten, können Sie ein WordPress-Plug-in verwenden. Ein beliebtes und gut bewertetes Plug-in ist Headers Security Advanced & HSTS WP.

Vorteile

• Einfache Konfiguration über das WordPress-Dashboard.
• Keine Notwendigkeit, Dateien direkt zu bearbeiten.

Empfehlung

Obwohl Plug-ins eine benutzerfreundliche Alternative bieten, sollten sie nur verwendet werden, wenn Sie sich mit der direkten Konfiguration von .htaccess oder functions.php unsicher fühlen. Weniger Plug-ins bedeuten in der Regel eine höhere Website-Performance und weniger potenzielle Fehlerquellen.

Zusammenfassung

Das Hinzufügen von HTTP-Security-Headern in WordPress ist eine wirkungsvolle Maßnahme, um die Sicherheit Ihrer Website zu erhöhen. Während die .htaccess-Methode die flexibelste und performanteste ist, bietet die functions.php-Methode eine gute Alternative bei eingeschränktem Zugriff. Plug-ins sind nützlich für weniger technisch versierte Nutzer, sollten jedoch sparsam eingesetzt werden. Wählen Sie die Methode, die am besten zu Ihren Bedürfnissen und Ihrem Kenntnisstand passt, und testen Sie Ihre Änderungen gründlich, bevor Sie sie live schalten.