HTTP-Security-Header erhöhen die Sicherheit und den Datenschutz Ihrer WordPress-Website, denn sie können den Schutz gegen Hackerangriffe dramatisch steigern. Leider ist ihr Einsatz unter WordPress-Installationen noch nicht sehr verbreitet. Das liegt zum einen daran, dass diese Sicherheitsmaßnahmen einiges an Fachwissen voraussetzten, zum anderen sind sie nicht sehr einfach umzusetzen. Mit diesem Beitrag helfen wir Ihnen, die Thematik zu verstehen und die Sicherheit Ihrer Website zu erhöhen.

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?

Rufen Sie eine Website auf, sendet Ihr Browser eine Anfrage an den entsprechenden Webserver, um von diesem die nötigen Dateien und Daten für das Anzeigen der Website zu erhalten. Browser und Webserver tauschen auch gleich noch ein paar zusätzliche Informationen aus. Der Browser übermittelt beispielsweise Ihrem Server, von welchem Gerät, mit welchem Betriebssystem und Browser die Website aufgerufen wird. Die Website betreffenden Informationen sind im ‚HTTP-Header‘ zusammengefasst. Diese Header-Informationen dienen hauptsächlich der Abstimmung. Es wird sichergestellt, dass der Browser mit den vom Server gelieferten Daten etwas anfangen kann.

Die HTTP-Security-Header gehören zu dem HTTP-Header, um die sicherheitsrelevanten Details anzugeben. Einige HTTP-Header, die indirekt mit Datenschutz und Sicherheit zu tun haben, können ebenfalls den HTTP-Sicherheits-Header zugeordnet werden. Da mittlerweile alle gängigen Browser diese HTTP-Header unterstützen, können Sie durch die Verwendung geeigneter Header die Widerstandsfähigkeit Ihrer WordPress-Website gegen viele gängige Angriffe, wie Cross-Site-Scripting (XSS) und Clickjacking verbessern.

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.

HTTP Strict-Transport-Security (HSTS)

Diese Funktion erzwingt die Verwendung von verschlüsselten HTTPS-Verbindungen anstelle der unsicheren (und veralteten) HTTP-Kommunikation. Natürlich muss zunächst mittels SSL-Zertifikat dafür gesorgt werden, dass die Website verschlüsselt kommunizieren kann.

Ein typischer HSTS-Header könnte lauten:

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

• ‚Strict-Transport-Security’ informiert den Browser, dass die Website nur über HTTPS aufgerufen werden kann.
• ‚max-age’ teilt dem Browser die Gültigkeit dieser Information in Sekunden mit (hier zwei Jahre).
• ‚includeSubDomains’ bezieht Subdomains mit ein, was auch weggelassen werden kann.
• Optional ist auch der ‚preload‘-Befehl, der anzeigt, dass die Site in einer globalen Liste von „HTTPS-only-Sites“ enthalten ist. Das Vorladen soll das Laden der Seiten beschleunigen und das Risiko von Man-in-the-Middle-Angriffen beim ersten Besuch einer Site eliminieren.

X-Frame-Options

Mit diesem Befehl können Sie verhindern, dass Ihre Inhalte in fremde Websites eingebettet werden. Der Aufruf Ihrer Website (oder Teile davon) auf Websites Dritter mit den Befehlen < frame >, <i. frame >, < embed > oder < object > werden unterbunden. So wehrt man Clickjacking-Attacken ab.

Es gibt drei Ausprägungen für diesen Befehl: ‚deny‘ unterbindet das Einbetten auf jeglichen Websites, ‚sameorigin‘ erlaubt die Integration auf der eigenen Website und ‚allow-from uri‘ ermöglicht das Einbinden auf der Website mit der Domain ‚uri‘.

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: "allow-from https://example.com/"

Anmerkungen: Bei einigen Tests hatten wir bei der Einstellung ‚deny‚ Probleme mit den Updates von Plug-ins, die nicht mehr möglich waren. Wählen Sie in diesem Fall ‚sameorigin‘.

X-Content-Type-Options

Ein Medientyp (auch bekannt als Multipurpose Internet Mail Extensions oder MIME-Typ) ist ein Standard, der die Art und das Format einer Datei oder eines Dokuments angibt. Richtig verwendet, sorgt dieser Standard dafür, dass zum Beispiel ein Word-Dokument, das Sie über Ihre Website anbieten, direkt mit der entsprechenden Software geladen wird.

Da viele Daten nicht richtig deklariert sind, versuchen Browser durch „MIME-Sniffing“ selbstständig herauszufinden, um welchen MIME-Typ es sich handelt, um eventuell das passende Programm zu laden oder die Daten im richtigen Format anzuzeigen. Die an sich gute Idee könnte allerdings von Hackern so ausgenutzt werden, dass sie schadhaften Programmcode durch eine mögliche Sicherheitslücke bei Ihnen auf den Server laden und tarnen (z. B: Javascript in Bildern), um damit die Rechner der Website-Besucher mit Schadcode zu infizieren.

Durch den Befehl ‚nosniff‘ werden die Browser daran gehindert, herauszufinden, welcher Dateityp sich hinter unbekannten Dateien verbirgt. So können sie nicht fälschlich ausgeführt oder heruntergeladen werden (Drive-by-Download-Attacken).

X-Content-Type-Options: nosniff

X-XSS-Protection

Hinweis: Der X-XSS-Protection-Header wird von modernen Browsern nicht mehr unterstützt. Das bedeutet, dass Sie, wenn Sie ältere Browser nicht unterstützen müssen, stattdessen Content-Security-Policy verwenden sollten, ohne unsafe-inline-Skripte zuzulassen. Das Problem: Der XSS-Schutz kann in einigen Fällen XSS-Schwachstellen in ansonsten sicheren Websites verursachen.

Der X-XSS-Protection-Header ist eine Funktion, die das Laden von Seiten verhindert, wenn sie „reflektierte“ Cross-Site-Scripting-Angriffe erkennen. Bei diesem Angriffstyp wird JavaScript- oder HTML-Code an die URL angehängt und so an die Website übergeben, dass er an die Website-Besucher zurückgegeben – also “reflektiert” – wird. So ließen sich dann z.B. Links anhängen, die bösartiges JavaScript im Browser der Nutzer ausführen. Die übliche Syntax ist:

X-XSS-Protection: 1; mode=block

Obwohl diese Schutzmaßnahmen in modernen Browsern weitgehend unnötig sind, wenn Websites eine entsprechende Content-Security-Policy implementieren (siehe unten), die die Verwendung von Inline-JavaScript deaktiviert (‚unsafe-inline‘), können sie dennoch Schutz für Benutzer älterer Webbrowser bieten, die CSP noch nicht unterstützen.

Referrer-Policy

Über diesen HTTP-Security-Header lässt sich steuern, ob und in welchen Fällen der sog. Referrer-Wert bei ausgehenden Links übergeben werden soll. Die Referer-Informationen geben einer aufgerufenen Website an, von wo der Request ausgelöst wurde. Führt zum Beispiel ein Link Ihrer Website zu einem externen Ziel, so wird der Browser dieser Website Ihre Domain als Ursprung mitteilen, so ein Besucher auf den Link klickt.

Der Referrer lässt sich nicht direkt für Angriffe nutzen, ist aber für den Datenschutz interessant. Über den Wert ‚no-referrer‘ lässt sich eine Übertragung grundsätzlich unterdrücken, womit die Herkunft der Nutzer beim Verlassen Ihrer Website vertuscht wird.

Referrer-Policy: "no-referrer"

Weitere Einstellungsmöglichkeiten sind möglich. Sie finden Sie bei Bedarf hier.

Permissions-Policy

Der Permission Policy-Header (ehemals Feature-Policy) steuert, welche Browser-Funktionen verwendet werden können, die für die Sicherheit oder den Datenschutz Ihrer Besucher relevant sind. Zu diesen Funktionen gehören beispielsweise das Einschalten von Webcam oder Mikrofon, der Abruf des Standorts oder die Aktivierung der Zahlungs-API, die zum Beispiel von ApplePay genutzt wird. Neben der Implementierung dieser Regeln für Ihre eigenen Inhalte kann er auch verhindern, dass externe iframes diese Browser-Funktionen verwenden, was ihn zu einem leistungsstarken Header zur Sicherung Ihrer Website macht.

Über die Permissions-Policy kann man somit den Datenschutz Ihrer Website verbessern, indem Sie Angriffe verhindern, die es auf die Daten Ihrer Website-Besucher abgesehen haben. Als Beispiel kann eine Regel im Permissions-Policy-Header wie folgt angegeben werden:

Permissions-Policy: geolocation=(self "https://beispiel.de"), camera=(), fullscreen=*

Über den Befehl ‚self‘ geben Sie die jeweilige Funktion für die aktuelle Website frei. Geben Sie eine Domain an, gilt die Freigabe für eben diese. Ein Stern ‚*‘ erteilt allen Quellen die Freigabe und ein leerer Eintrag ‚()‘ deaktiviert die Funktion grundsätzlich. In dem oberen Beispiel wird also die folgende Richtlinie definiert: Die Geolocation-Berechtigung gilt für die eigene Website und die Domain ‚beispiel.de‘. Der Kamerazugriff ist für alle Dokumente deaktiviert und der Vollbildmodus kann potenziell von jeder Quelle aufgerufen werden.

Die wichtigsten Befehle findem Sie im Folgenden. Eine ausführliche Anleitung der Permission-Policy gibt es bei Github.

Permissions-Policy: geolocation=(), midi=(), camera=(), usb=(), payment=(), vr=(), speaker=(), ambient-light-sensor=(), gyroscope=(), microphone=(), usb=(), interest-cohort=()

Update April 2021: Wir haben die Liste der Permission-Policy-Befehle um den Begriff interest-cohort=() ergänzt, der Googles FLoC auf Ihrer Website verhindert.

Content Security Policy (CSP)

Nun wir es kniffelig, denn die Einstellungen der CSP sind sehr komplex und müssen individuell für Ihre Website ausgewählt, konfiguriert und getestet werden. Lassen Sie im Zweifel diesen Bereich aus. Das ist nicht optimal, aber besser, als keinen oder falsch konfigurierten Schutz.

Sind Sie experimentierfreudig oder mutig (oder beides), dann können Sie mithilfe der CSP definieren, welche Ressourcen wie JavaScript, CSS — oder so ziemlich alles, was der Browser lädt — auf Ihrer Website erlaubt ist und von welcher Quelle sie stammen dürfen, damit sie als vertrauenswürdig gelten und somit ausgeführt werden. So können Sie die schon weiter oben beschriebenen Cross-Site-Scripting-Angriffe verhindern. Sollten Sie keine iframes auf Ihrer Websites nutzen und einen minimalen Schutz gegen diese XSS-Angriffe einrichten wollen, nutzen Sie die folgende (minimale) CSP-Richtlinie:

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

Die Herausforderung der Konfiguration von WordPress-Websites ist, dass Medien, Inhalte und Funktionen nicht selten von externen Servern geladen werden. Zum Beispiel werden nicht selten (trotz DSGVO) immer noch häufig Google Fonts von Google-Servern geladen. Diese externen Quellen müssen einzeln akkurat in die CSP übernommen werden, damit die Website weiterhin funktioniert und die höchstmögliche Sicherheit aufweist.

Ein tolles Werkzeug, das zum einen die Komplexität der CSP vermittelt, Sie zum anderen dabei unterstützt die CSP Ihrer Website zu entwickeln, finden Sie unter der Adresse CSP is Awesome.

Und noch ein Tool: Zwar unterstützen so ziemlich alle modernen Browser-Generationen die Content Security Policy, werten wir aber unsere Besucherdaten aus, finden wir immer noch ein recht reges Treiben von Besuchern auf unserer Website mit veralteten Browsern, wie den Internet Explorer von Microsoft. Möchten Sie testen, ob Ihr Webbrowser die CSP-Einstellungen unterstützt, nutzen Sie den CSP Browser Test.

So testen Sie Ihre HTTP-Security-Header-Einstellung

Bevor Sie sich in das Projekt stürzen, Ihre Website weiter abzusichern, sollten Sie zunächst überprüfen, ob auf Ihren Server nicht schon Sicherheitsrichtlinien durch Ihren Hoster eingestellt sind. Dazu bieten sich je nach Geschmack die Dienste von siwecos.de, securityheaders.com und observatory.mozilla.org an.

Natürlich ist es sehr zu empfehlen, dass Sie auch nach der Einrichtung eines HTTP-Security-Header diese Tests durchführen. Aber nicht nur das; Sie sollten auch unbedingt Ihre Website nach Darstellungsfehlern sichten und ausführliche Funktionstests durchführen. Werden zum Beispiel noch externe Schriften geladen, Sind die YouTube-Videos noch aufrufbar, Funktioniert Ihre Hauptnavigation noch, lassen sich Plug-ins noch updaten, um nur ein paar mögliche Fehler zu nennen.

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

Grundsätzlich gibt es Möglichkeiten den HTTP-Security-Header bereits auf der Server-Ebene einzutragen. Auf diese Möglichkeiten gehen wir hier nicht ein. Wir erklären auch nicht, wie man die Sicherheits-Einstellungen direkt im HTML-Code als Meta-Tag definiert. Wir beschränken uns auf die gängigen Optionen in Verbindung mit der WordPress-Sicherheit.

WICHTIG: Bevor Sie die folgenden Dateien bearbeiten tun Sie sich einen Gefallen und legen zuvor Kopien der entsprechenden Dateien an und sichern am besten auch noch die Datenbank.

Und: Kopieren Sie nicht einfach die folgenden Beispiele, sie können funktionieren, müssen es aber nicht. Optimieren Sie die Einstellungen vielmehr Schritt für Schritt nach Ihren Bedürfnissen.

Einfügen der HTTP-Security-Header über die .htaccess-Datei

Wir empfehlen das Einfügen der Sicherheitsregeln über die .htaccess-Datei. Die .htaccess-Datei finden Sie im Hauptverzeichnis Ihrer WordPress-Installation. Sie wird automatisch von WordPress bei der Installation angelegt. Der Code, den Sie möglichst weit zu Beginn der Datei einfügen, könnte wie folgt aussehen:

<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>

Einbinden der HTTP-Security-Header über die functions.php

Falls Sie keinen Zugriff auf die .htaccess-Datei haben sollten, können Sie alternativ die HTTP-Security-Header auch über die functions.php (idealerweise in einem Child-Theme) eintragen. Dazu werden beispielhaft folgende Zeilen am Ende der Datei eingefügt:

/* 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');
}

Einbinden der HTTP-Security-Header über ein Plug-in

Wir vermeiden gerne Plugins und glauben, dass man bei der Konfiguration der Sicherheitseinstellung erfahren genug sein sollte, die Einstellung über die Dateien .htaccess oder wp-config.php direkt vorzunehmen, doch zur Vollständigkeit sei erwähnt, dass es ein Plug-in namens Headers Security Advanced & HSTS WP für das Einbinden der HTTP-Security-Header gibt, das sehr gute Bewertungen vorweisen kann.

Zusammenfassung

Mithilfe der HTTP-Security-Header können Sie die Sicherheit und den Datenschutz Ihrer Website verursacht durch Hackerangriffe dramatisch steigern. Wir haben versucht, das komplexe Thema der HTTP-Security-Header so verständlich wie möglich zu erklären, um es einem breiteren Publikum zu vermitteln. Das sollte aber nicht darüber hinwegtäuschen, dass es sich bei der Konfiguration um eine Aufgabe handelt, die eine gewisse Erfahrung und Verständnis für das Thema erfordert.