Was sind WordPress Security Header? Bei jedem Aufruf einer Webseite gibt es eine Kommunikation zwischen dem Server, auf dem eine Webseite liegt, und Ihrem Browser. Diese Kommunikation findet im HTTP-Protokoll statt. Bei jedem dieser Aufrufe, die an den Server gesendet werden, sendet der Server eine Antwort zurück.
Innerhalb dieser Antwort, gibt es eine Reihe an Informationen, die vom Server an den Browser zurückgesendet werden – die HTTP Header. Diese enthalten beispielsweise Informationen über die Kodierung des Inhalts, über den Content-Type des Inhalts, den HTTP-Statuscode oder eine Reihe an weiteren Informationen.
Mithilfe von HTTP Security Headern können Sie diese Kommunikation zu einem gewissen Teil beeinflussen, verbessern und absichern. Hierdurch können Sie die Sicherheit einer Webseite erhöhen und sogar die Geschwindigkeit und Performance von Webseiten verbessern.
Relevanz von HTTP Security Headern für WordPress
HTTP Security Header sind nicht ausschließlich, aber auch für WordPress Seiten relevant. Durch die Tatsache, dass WordPress als meist genutzte Software zur Erstellung und Darstellung von Webseiten gilt, hat das Thema HTTP Security Header im Bezug auf WordPress vielleicht nochmal eine höhere Relevanz.
Dennoch gilt: jede Webseite profitiert von der Nutzung von Security Headern. Welche HTTP Security Header es gibt und wie Sie diese auf einer (WordPress)-Webseite implementieren und testen, wird in diesem Artikel ausführlich erklärt.
Die folgende Auflistung behandelt nicht komplett alle Security Header, die es gibt. Die Auswahl ist beschränkt auf diese, die für WordPress relevant sind und die in diesem Zusammenhang einen Mehrwert bieten.
X-Frame Header WordPress
Was ist der X-Frame Security Header? Der X-Frame Security Header bestimmt, ob eine Webseite innerhalb von Objekten, Frames oder iFrames geladen werden darf. Sprich: ob Ihre Webseite auf fremden Webseiten auf diese Weise eingebunden werden darf. Wenn Sie das unterbinden, erhöhen Sie die Sicherheit gegen Clickjacking-Angriffe erheblich.
Welche Werte kann der X-Frame Security Header besitzen? Für den X-Frame Security Header gibt es drei mögliche Werte, die für diesen benutzt werden können.
- DENY: verhindert die Einbettung Ihrer Webseite grundsätzlich, egal auf welcher Webseite
- SAMEORIGIN: erlaubt die Einbettung Ihrer Webseite, wenn die Anfrage von der gleichen Ursprungsdomain kommt, sprich auf einer Unterseite Ihrer eigenen Webseite
- ALLOW-FROM uri: erlaubt die Einbettung explizit für eine genannte URL
X-Content-Type Header WordPress
Was ist der X-Content-Type Security Header? Der X-Content-Type Header ist dafür da, um sogenannte „MIME Sniffing“-Attacken zu unterbinden. Wenn der MIME-Typ einer Datei beispielsweise als „text/plain“ angegeben ist, dann wird er vom Browser mit diesem Security Header auch immer als solcher behandelt.
Ohne diese Einstellung können potenzielle Angreifer:innen versuchen, den MIME-Type einer Datei anders zu interpretieren und beispielsweise Quellcode runterladen oder hochgeladene Dateien können getarnt werden, um beispielsweise Drive-By Downloads zu initiieren.
Welche Werte kann der X-Content-Type Security Header besitzen? Folgende Werte sind für diesen Header möglich:
- nosniff: verhindert, dass MIME-Typen geändert werden können, indem der Browser die Datei genau so zu interpretieren hat, wie der MIME-Typ auch angegeben ist
- none: erlaubt dem Browser selber zu entscheiden, wie Dateien interpretiert werden
X-XSS-Protection Header WordPress
Was ist der X-XSS-Protection Security Header? Mit diesem Security Header wird die in Browsern enthaltene XSS Erkennung aktiviert. Diese sorgt dafür, bei potenziellen XSS-Attacken (Cross Site Scripting), diese automatisch zu erkennen und abzuwehren. Dieser Header bietet ebenfalls einen wichtigen und guten Mehrwert bei der Sicherheit Ihrer Webseite.
Welche Werte kann der X-XSS-Protection Security Header besitzen? Die folgenden Werte können für diesen Header gesetzt werden:
- 1; mode=block: aktiviert den „Block“-Modus des Browsers, potenzieller schädlicher Code wird, wenn er erkannt wird, geblockt und nicht ausgeführt
- 0: deaktiviert den eingebauten XSS-Filter des Browsers
Strict-Transport-Security Header (HSTS) WordPress
Was ist der Strict-Transport-Security Header (HSTS)? Mit dem Strict-Transport-Security Header (HSTS) können Sie den Browser dazu zwingen, ausschließlich über eine verschlüsselte HTTPS Verbindung auf die Webseite zuzugreifen.
Neben der Tatsache, dass dies sowieso im Zuge der DSGVO wichtig ist, sobald personenbezogene Daten auf der Webseite verarbeitet werden, können Sie hiermit außerdem Man-in-the-Middle Attacken verhindern, bei denen Angreifer:innen sich in die Verbindung zwischen dem aufrufenden Browser und Ihrer Webseite einklinken.
Welche Werte kann der Strict-Transport-Security Header (HSTS) besitzen? Für den Strict-Transport-Security Header können folgende Werte benutzt werden.
- max-age=31536000: Hiermit definieren Sie (in Sekunden), wie lange der aufrufende Browser die Seite nur über HTTPS aufrufen können soll. Der Standardwert hier liegt bei 31536000 Sekunden, was einem Jahr entspricht. Kleinere Werte sind jedoch ebenfalls denkbar.
- includeSubDomains: Optionaler Wert, der alle Subdomains der Webseite für diesen Header einschließt. Hierfür muss ein SSL Zertifikat für die Subdomains eingerichtet sein. Von der Nutzung wird eher abgeraten
- preload: Optionaler Wert. Lädt die von Ihnen benutzte Domain in eine sogenannte preload-Liste der Browserhersteller. Dadurch wird HSTS direkt vom Browserhersteller eingebunden. Falls es Probleme mit beispielsweise dem SSL oder anderen Konfigurationen Ihrer Webseite gibt, wird die Seite nicht geladen. Von dieser Konfiguration ist abzuraten.
Content-Security-Policy (CSP) WordPress
Was ist die Content-Security-Policy (CSP)? Mit der Content-Security-Policy (CSP) ist es möglich festzulegen, welche Ressourcen auf Ihrer Webseite geladen werden dürfen und aus welchen Quellen diese stammen dürfen. Auch dieser Security Header bietet vor allem Schutz gegenüber XSS-Attacken.
Auf diese Weise können Sie beispielsweise festlegen, dass nur gezielt eingebundene CSS- und JS-Dateien auf Ihrer WordPress Webseite und von Ihrer Webseite abgerufen werden dürfen.
Es gibt in diesem Blog bereits einen Artikel darüber, wie Sie eine Content-Security-Policy (CSP) in WordPress implementieren. Dieser beinhaltet eine ausführliche Erklärung, Szenarien und Implementierungsbeispiele für alle möglichen Konfigurationen Ihrer WordPress Seite.
Referrer-Policy WordPress
Was ist die Referrer-Policy? Der Referrer-Policy Header gibt an, ob Informationen über die Herkunft von Besuchenden Ihrer Webseite übertragen werden sollen. Sendet der Browser diese Information mit können Sie genau nachvollziehen, von welcher Quelle (zum Beispiel eine andere Webseite) der Besuchende Ihre Seite erreicht hat.
Auch diese Information ist standardmäßig ein Teil des HTTP-Headers, kann aber auch explizit durch die Security Header deaktiviert werden. Dies sorgt für einen besseren Schutz der Privatsphäre der Besuchenden.
Welche Werte kann der Referrer-Policy Header besitzen? Übermittelt werden können die drei Parameter ursprüngliche URL, der Pfad und ebenso der Query String. Folgende Werte können für die Referrer-Policy angegeben werden.
- no-referrer: Es werden grundsätzlich keine Referrer-Informationen vom Browser gesendet
- no-referrer-when-downgrade: Der Browser wird nur Informationen senden, wenn eine Verbindung über HTTPS besteht, nicht jedoch bei einer unverschlüsselten HTTP Verbindung. Sendet bei gleichbleibendem Sicherheitslevel alle drei Parameter
- same-origin: Referrer wird nur für Anfragen übermittelt, die an dieselbe, ursprüngliche Webseite gesendet werden (hier werden alle drei Parameter mitgeschickt, bei anderen als der ursprünglichen Webseite nur die URL)
- origin: Referrer wird ebenfalls nur für Anfragen an die ursprüngliche Webseite übermittelt, jedoch ohne spezifische Pfade oder Querys dabei zu übermitteln (sendet nur die URL)
- strict-origin: Ist fast identisch zu „origin“ wird jedoch nicht übermittelt, wenn die Anfrage von einer HTTPS verschlüsselten Seite zu einer unverschlüsselten HTTP Seite führt (sendet alle drei Parameter)
- strict-origin-when-cross-origin: ist identisch zur strict-origin Direktive, bei Anfragen von anderen als der ursprünglichen Webseite werden keine Informationen gesendet (heutzutage die Standard Direktive)
- origin-when-cross-origin: Wenn eine same-origin Anfrage gesendet wird, werden alle drei Parameter mitgesendet, bei cross-origin Anfragen oder bei Anfragen mit einer niedrigeren Sicherheit (z.B: von HTTPS auf HTTP) wird nur die URL gesendet
- unsafe-url: Alle Parameter werden mit dem HTTP Request mitgesendet, selbst wenn die Sicherheit minimal ist
Feature-Policy WordPress
Was ist die Feature-Policy? Der Feature-Policy Header ermöglicht es, bestimmte Browser-Funktionen für Ihre Webseite zu deaktivieren. Es gibt eine Vielzahl an Features, die in einem Browser heutzutage integriert sind. Eine vollständige Übersicht über Features der Feature Policy finden Sie auf der Seite von Mozilla.
Welche Werte kann der Feature-Policy Header besitzen? Beispiele für diese Features können die Kamera, das Mikrofon oder auch die Geolokalisierung sein. Eine gesamte Übersicht gibt es in der im letzten Abschnitt verlinkten Seite von Mozilla.
Wie kann ich prüfen, welche HTTP Security Header auf meiner Seite aktiv sind?
Es gibt mehrere Möglichkeiten um zu prüfen, welche HTTP Security Headers Sie bereits auf Ihrer Seite aktiv haben beziehungsweise wie diese konfiguriert sind. Hierfür gibt es sehr hilfreiche Webseiten, die Ihnen neben der eigentlichen Prüfung auch noch zusätzliche Hinweise und weiterführende Informationen bieten können. Einige davon sind:
Wenn Sie nicht möchten, dass Ihre getestete Webseite auf der Startseite angezeigt wird, dann aktivieren Sie vor der Suche den Haken bei „Hide results“.
Auch hier gilt, dass Sie einen Haken (bei „Don’t include my site in the public results“) aktivieren müssen wenn Sie nicht möchten, dass Ihre getestete Webseite öffentlich einsehbar ist
Implementierung von HTTP Security Headern in WordPress
Implementierung in Apache mithilfe der .htaccess
Wie sieht eine Implementierung der Security-Header in WordPress mit Apache aus? Eine Implementierung mithilfe von .htaccess unter Apache in WordPress kann wie folgt aussehen. Die Implementierung muss von Ihnen innerhalb der .htaccess, die im Root-Verzeichnis der WordPress-Installation liegt, erfolgen.
Wenn Sie Zugriff auf die Konfiguration des Servers haben, können Sie die Security-Header auch in die Datei /etc/apache2/sites-enabled/example.conf einfügen.
# X-Frame-Options
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
# X-Content-Type-Options
Header set X-Content-Type-Options "nosniff"
# X-XSS-Protection
Header set X-XSS-Protection "1; mode=block"
# Strict-Transport-Security
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Content-Security-Policy
Header set Content-Security-Policy "default-src 'none'; img-src 'self'; script-src 'self' https://code.jquery.com; style-src 'self'"
# Referrer-Policy
Header set Referrer-Policy "same-origin"
# Feature-Policy
Header set Feature-Policy "geolocation 'self'; vibrate 'none'"
</IfModule>Beispiel für Security Header auf einem Apache Server
Implementierung in Nginx mithilfe der security.config
Wie sieht eine Implementierung der Security-Header in WordPress mit Nginx aus? Fügen Sie eine Implementierung, die wie folgt aussehen kann, in Ihre nginx.conf oder Ihre security.conf ein.
# X-Frame-Options
add_header X-Frame-Options "SAMEORIGIN";
# X-Content-Type-Options
add_header X-Content-Type-Options nosniff;
# X-XSS-Protection
add_header X-XSS-Protection "1; mode=block";
# Strict-Transport Security
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';
# Content-Security-Policy
add_header Content-Security-Policy "default-src 'self'; font-src *;img-src * data:; script-src *; style-src *";
# Referrer-Policy
add_header Referrer-Policy "strict-origin";
# Feature-Policy
add_header Permissions-Policy "geolocation 'self'; vibrate 'none'";Beispiel für Security Header auf einem Nginx Server
Implementierung in IIS mithilfe der web.config
Wie sieht eine Implementierung der Security-Header in WordPress mit IIS aus? Um Ihre Security-Header unter einem IIS Server zu implementieren, müssen Sie auf die grafische Oberfläche Ihres IIS Servers zurückgreifen. Navigieren Sie zu dem Bereich Home und hier in den Bereich Connections. Suchen Sie hier den Punkt HTTP Response-Header.
Hier fügen Sie jeweils die folgenden Punkte hinzu. Passen Sie die Security-Header so an, wie Sie sie benötigen.
Name: X-Frame-Options
Value: SAMEORIGIN
Name: X-Content-Type-Options
Value: nosniff
Name: X-Xss-Protection
Value: 1; mode=block
Name: Strict-Transport-Security
Value: max-age=31536000; includeSubDomains
Name: Content-Security-Policy
Value: "default-src 'self'; font-src *; img-src * data:; script-src *; style-src *"
Name: Referrer-Policy
Value: strict-origin
Name: Permissions-Policy
Value: "geolocation 'self'; vibrate 'none'"Beispiel für Security Header auf einem IIS
WordPress Security Header Plugin
Wie kann ich Security-Header mit einem Plugin in WordPress implementieren? Es gibt auch die Möglichkeit, die Security-Header mit einem Plugin in WordPress zu implementieren. Hierbei gibt es extra Plugins, die nur für diesen Zweck entwickelt wurden und Plugins, die diese Funktion quasi nebenbei miterfüllen.
Ein Beispiel, für ein Plugin welches explizit für das Einsetzen von Security-Headern in WordPress entwickelt wurde, ist das Headers Security Advanced & HSTS WP Plugin.
Ein Plugin, welches Security-Header neben vielen weiteren Funktionen anbietet, ist das Plugin W3 Total Cache.
Natürlich sind Security Header nicht die Allzwecklösung oder Wunderwaffe, wenn es um die Absicherung Ihrer WordPress-Seite geht. Als Betreiber:in einer WordPress-Seite sollten Sie sich ausreichend Gedanken um die Absicherung machen. Ein Teil hiervon können die Security-Header sein.
Diese sollten jedoch als zusätzliche Maßnahme gesehen werden, nachdem Sie bereits alle anderen Absicherungen ausgeschöpft haben. Hierzu zählen beispielsweise eine effiziente Rechteverwaltung, ein Backup- und Update-Plan oder auch der Verzicht auf unnötig viele Plugins.
