So fügen Sie HTTP-Sicherheitsheader in WordPress hinzu

WordPress ist das weltweit beliebteste Content Management System (CMS) und betreibt mehr als 43 % aller Websites im Internet.Aufgrund seiner weiten Verbreitung ist es jedoch ein häufiges Ziel für Hacker.

Brute-Force-Angriffe, Schwachstellen beim Hochladen von Dateien und Cross-Site-Scripting-Angriffe tragen alle zur anhaltenden Bedrohung bei.

Glücklicherweise gibt es mehrere Möglichkeiten, Ihre Website sicherer und weniger anfällig für Angriffe zu machen. Und hier kommen HTTP-Header ins Spiel.

Durch die Implementierung von HTTP-Sicherheitsheadern können Sie die Aktionen einschränken, die Browser und Server auf Ihrer Website ausführen können, und eine zusätzliche Sicherheitsebene hinzufügen. Diese Header erschweren es Angreifern erheblich, Schwachstellen auf der Clientseite auszunutzen.

In diesem Artikel besprechen wir, was HTTP-Sicherheitsheader sind und wie Sie sie effektiv auf Ihrer Website implementieren können.

Was genau sind HTTP-Sicherheitsheader?

HTTP-Sicherheitsheader sind eine Gruppe von Anweisungen, die von Webanwendungen verwendet werden, um Sicherheitsmaßnahmen in Webbrowsern zu implementieren. Diese Header werden zwischen dem Webbrowser (dem Client) und dem Server ausgetauscht, um die Sicherheitsparameter der HTTP-Kommunikation zu identifizieren. Dieser Informationsaustausch teilt dem Browser mit, wie er sich während seiner Interaktionen mit Ihrer Website verhalten soll, und regelt Prozesse wie die Anzeige von Fehlern und die Verwaltung des Caches.

Diese zusätzliche Sicherheit und Effizienz hängt natürlich weitgehend vom Browser ab. Ältere Webbrowser verfügen nicht über das gleiche Maß an Sicherheit oder Kompatibilität und verarbeiten HTTP-Sicherheitsheader möglicherweise nicht richtig, vollständig oder überhaupt nicht. Dies kann möglicherweise bedeuten, dass trotz aller Bemühungen, den Besucher zu schützen, sein veralteter Browser ihn immer noch angreifbar macht. Als Website-Entwickler sollten wir alles tun, was wir können, aber akzeptieren, dass es letztendlich in der Verantwortung des Besuchers liegt, sicherzustellen, dass er auf seinem Computer aktuelle Software verwendet. Solange sie einen modernen, aktuellen Webbrowser verwenden, funktioniert unsere Verwendung von HTTP-Sicherheitsheadern mit ihrer Browsersoftware, um sie zu schützen.

Unser Hauptanliegen ist jedoch, dass HTTP-Sicherheitsheader Ihre Website vor häufigen Angriffen wie Cross-Site-Scripting und Brute-Force-Angriffen schützen.Die effektivste Möglichkeit, diese Header zu implementieren, besteht darin, sie auf Ihr WordPress-Hosting-Konto (Serverebene) festzulegen und eine Website-Anwendungsfirewall auf DNS-Ebene wie Cloudflare zu verwenden.

Sie müssen jedoch bedenken, dass das Hinzufügen von HTTP-Sicherheitsheadern zwar zur Verbesserung der Sicherheit Ihrer Website beitragen kann, dies jedoch nur ein Aspekt der Website-Sicherheit ist und in Verbindung mit anderen Sicherheitsmaßnahmen verwendet werden sollte. Dazu gehört, dass Sie Ihre Anwendungen und Plugins auf dem neuesten Stand halten, Ihre sensiblen Daten verschlüsseln und Site-Daten und Konfigurationsdateien sichern.

Bevor wir verschiedene Methoden zum Hinzufügen von Sicherheitsheadern besprechen, schauen wir uns jeden Header im Detail an und verstehen, warum er wichtig ist.Wenn Sie bereits mit Sicherheitsheadern vertraut sind, können Sie mit dem folgenden Abschnitt fortfahren.

Die Arten von WordPress-HTTP-Sicherheitsheadern

Es gibt mehrere HTTP-Sicherheitsheader, die mit Ihrer WordPress-Website verwendet werden können, um den Schutz zu verbessern. Werfen wir einen Blick auf einige der wichtigsten.

1. X-XSS-Schutz-Sicherheitsheader

Dieser Sicherheitsheader wird zum Konfigurieren von Cross-Site-Scripting (XSS) verwendet, einer Sicherheitslücke, die es nicht authentifizierten Dritten ermöglicht, Code im Namen einer anderen Website im Browser auszuführen.

Es verhindert viele XSS-Angriffe auf Ihre Website, indem es das Rendern der Website stoppt, wenn ein Angriff erkannt wird. X-XSS nutzt die sicherere Option, die Website nicht vollständig zu laden, anstatt zu versuchen, die Seite durch Ersetzen potenziell schädlicher Elemente zu desinfizieren.

Der Header kann einen dieser verschiedenen Werte haben:

• X-XSS-Protection: 0 Deaktiviert die XSS-Filterung (nicht empfohlen)
• X-XSS-Protection: 1 Aktiviert die XSS-Filterung, die in den meisten Browsern normalerweise die Standardeinstellung ist. Wenn ein XSS-Angriff erkannt wird, entfernt der Browser die unsicheren Teile der Seite (Bereinigung).
• X-XSS-Schutz: 1; mode=block Aktiviert XSS-Filterung, aber anstatt die Seite zu bereinigen, verhindert der Browser das Rendern der Seite (empfohlen)
• X-XSS-Schutz: 1; report=<reporting-uri> Aktiviert XSS-Filterung. Der Browser bereinigt die Seite und meldet den Verstoß, wenn ein Cross-Site-Scripting-Angriff erkannt wird.

2. Sicherheitsheader für X-Frame-Optionen

Der X-Frame-Options-Sicherheitsheader kann verwendet werden, um verschiedene Brute-Force-Angriffe und DDOS-Angriffe zu verhindern . Am effektivsten ist er jedoch gegen Crossjacking von Iframes und Clickjacking auf Ihrer WordPress-Website.Mit diesem Header können Sie entscheiden, ob eine Seite Ihrer Website mithilfe von Iframe-Elementen im Browser eingebettet werden kann oder nicht.

Die X-Frame-Option schützt Ihre Website vor Klickdiebstahl, indem sie verhindert, dass sich Iframes mit Ihrer Website füllen. Es gibt zwei verschiedene Anweisungen, aus denen Sie wählen können –DENY und SAMEORIGIN. Es funktioniert mit allen gängigen Webbrowsern wie Chrome, Safari, Firefox und Opera.

 X-Frame-Optionen: DENY

 X-Frame-Optionen: SAMEORIGIN

Bei Angabe mit DENY verursacht der X-Frame-Options-Header einen Fehler, wenn ein Browser versucht, die Seite innerhalb eines Frames zu laden, wenn er von anderen Websites geladen wird. Versuche, dies zu tun, schlagen auch fehl, wenn sie von der ursprünglichen Site in einen Iframe geladen werden. Wenn wir andererseits SAMEORIGIN angeben, können wir die Seite immer noch innerhalb eines Frames verwenden – solange die Site, die sie in einen Frame einfügt, dieselbe ist wie die, die die Seite bereitstellt.

Dieser Header ist besonders wichtig für Webseiten, die vertrauliche Informationen enthalten, und Seiten, die Informationen einbetten, wie z. B. Zahlungsgateways und Formulare.

3. HTTP Strict Transport Security (HSTS)-Header

Bei der HTTP Strict-Transport-Security handelt es sich um einen Sicherheitsantwortheader, der von einem Webserver an den Webbrowser eines Benutzers gesendet wird, um ihn darüber zu informieren, dass auf die Website nur über HTTP und niemals über unverschlüsseltes HTTP zugegriffen werden sollte.

Dieser Header bietet einen Mechanismus, um die Verwendung von HTTPS durch den Browser zu erzwingen , selbst wenn der Benutzer „http://“ in die Adressleiste eingibt oder einem HTTP-Link folgt.Es kann außerdem verhindern, dass Benutzer abgelaufene oder ungültige SSL/TLS-Zertifikate und andere Browserwarnungen ignorieren. Der HSTS-Wert wird pro Browser festgelegt, der die Website besucht. Es wird nicht pro Maschine festgelegt.

Der HSTS-Header bietet die Möglichkeit, beliebige Subdomains einzuschließen – Sie können die Direktive „includeSubDomains“ verwenden, um das gleiche Sicherheitsniveau von der Root-Domain zu übernehmen. Dies bedeutet, dass auf lokale Entwicklungen mit der Domäne (oder Subdomänen) nicht mehr über HTTP zugegriffen werden kann, da der Browser nur HTTPS-Verkehr zulässt.

Wenn Sie beispielsweise HSTS-Header auf example.com mit der erforderlichen „includeSubdomains “-Direktive haben, können Sie nach dem Besuch von example.com nicht mehr über unsichere Verbindungen auf Subdomains von example.com zugreifen. Seien Sie daher vorsichtig, wenn Sie sich für die Verwendung von „includeSubdomains“ entscheiden, da dies Auswirkungen auf Ihre anderen Domains haben könnte.

Sobald ein Browser einen HSTS-Header von einer Site empfängt, merkt er sich die HSTS-Richtlinie für die angegebene Dauer und aktualisiert alle zukünftigen Anfragen an die Site automatisch auf HTTPS. Dies hilft bei der Vermeidung von Man-in-the-Middle-Angriffen, Lauschangriffen und anderen Formen der Manipulation, indem sichergestellt wird, dass die gesamte Kommunikation zwischen Browser und Server verschlüsselt ist.

Die Syntax für diesen Header lautet:

 # Ohne includeSubDomains-Direktive
<IfModule mod_headers.c>
Header-Satz Strict-Transport-Security: „max-age=63072000;“
</IfModule>
# Mit includeSubDomains-Direktive
<IfModule mod_headers.c>
Header-Set Strict-Transport-Security „max-age=31536000; includeSubDomains; preload“ 
</IfModule>

Die max-age=<expire-time> -Direktive gibt die Zeit (in Sekunden) an, die der Browser beachten soll, dass auf eine Site nur über HTTPS zugegriffen werden kann. Im obigen Beispiel ist das maximale Alter beispielsweise auf zwei Jahre festgelegt. Wenn Sie sich für Servebolt CDN oder Accelerated Domains von Servbolt entschieden haben, verfügen Sie automatisch über 1 Jahr HSTS-Länge.

4. Referrer-Policy-Header

Dieser HTTP-Header steuert, wie viele über den Referrer-Header gesendete Referrer-Informationen in Anfragen enthalten sein sollen. Es begrenzt die Menge an Informationen, die gesendet werden, wenn ein Website-Besucher auf einen Link klickt. Dadurch wird verhindert, dass vertrauliche Informationen an andere Websites weitergegeben werden , beispielsweise die URL einer Seite mit privaten Informationen.

Es kann mehrere Werte haben – hier ein kurzer Überblick:

• no-referrer: Der Referer-Header wird unter keinen Umständen gesendet.
• No-referrer-when-downgrade: Der Referrer-Header wird nicht gesendet, wenn von einer HTTPS-Site zu einer HTTP-Site navigiert wird.
• Ursprung: Der Referer-Header enthält nur den Ursprung (Schema, Host und Port) der verweisenden Seite.
• Origin-when-cross-origin: Der Referrer-Header enthält die vollständige URL der verweisenden Seite, wenn Sie zwischen Seiten innerhalb desselben Ursprungs navigieren, und nur den Ursprung, wenn Sie zu einem anderen Ursprung navigieren.
• Strict-Origin: Der Referer-Header enthält nur den Ursprung der verweisenden Seite und wird nicht für Cross-Origin-Anfragen gesendet.
• Strict-Origin-When-Cross-Origin: Der Referer-Header enthält den Ursprung der verweisenden Seite und wird nicht für Cross-Origin-Anfragen gesendet, mit Ausnahme von Origins derselben Website. Wir empfehlen die Verwendung dieser Einstellung, da sie den Nutzen des Headers beibehält und gleichzeitig das Risiko von Datenlecks verringert.
• Unsichere URL: Der Referer-Header sendet den Ursprung, den Pfad und die Abfragezeichenfolge, wenn eine Anfrage ausgeführt wird, unabhängig von der Sicherheit.

Eine ausführliche Diskussion zum Referrer-Richtlinien-Header finden Sie im Artikel von Google web.dev über Best Practices für Referrer-Richtlinien .

5. X-Content-Type-Options-Header

Der X-Content-Type-Options-Header wird vom Server in einer HTTP-Antwort gesendet, um Browser über MIME-Typen zu informieren. Der Zweck dieses Headers besteht darin, zu verhindern, dass Browser Dateien als einen anderen MIME-Typ als den im Header angegebenen interpretieren .

Dieser Header kann den einzelnen Wert „nosniff“ haben. Die Syntax lautet wie folgt:

 X-Content-Type-Options: nosniff

Es ist sehr wirksam gegen MIME-Verwirrungsangriffe – die Verwendung dieses Sicherheitsheaders kann verhindern, dass der Browser Dateien auf unerwartete Weise interpretiert, was zu Sicherheitslücken führen könnte. Wenn ein Angreifer beispielsweise eine Datei mit der Erweiterung .jpg hochlädt, die jedoch keinen Inhalt enthält, da es sich tatsächlich um ein Skript handelt, verhindert das Setzen des X-Content-Type-Options- Headers auf „nosniff“, dass der Browser das Skript ausführen kann. Dadurch werden Benutzer vor potenziellen Sicherheitsverletzungen geschützt.

6. Header der Content Security Policy(CSP).

Content-Security-Policy ist ein Sicherheitsheader, der zur Angabe des Ursprungs des Inhalts verwendet wird und einen Mechanismus für den Inhalt bereitstellt, der in einer Website oder einer Webanwendung geladen und ausgeführt werden darf. Durch die Angabe einer Reihe von Richtlinien kann dieser Header die auf einer Webseite zulässigen Inhaltstypen einschränken und verschiedene Arten von Sicherheitsbedrohungen abschwächen. Es handelt sich um eine zusätzliche Sicherheitsebene gegen Cross-Site Scripting (XSS)- und Data-Injection-Angriffe, die für Straftaten wie Datendiebstahl, Website-Verunstaltung und Malware-Verbreitung eingesetzt werden.

Neben der Steuerung der Ressourcentypen, die geladen werden können, bietet der Content-Security-Policy-Header auch eine Möglichkeit, den Browser anzuweisen, wie er mit Verstößen gegen die im Header angegebenen Richtlinien umgehen soll. Beispielsweise könnte eine Richtlinie festlegen, dass der Browser eine Warnung veröffentlichen oder das Laden der Ressource blockieren soll, wenn eine Ressource gegen die Richtlinie verstößt.

Der Server muss so konfiguriert sein, dass er den Content-Security-Policy-Header zurückgibt, damit die Richtlinien funktionieren. Sie können den CSP-HTTP-Header verwenden, um Ihre Richtlinie wie folgt anzugeben:

 Content-Security-Policy: Richtlinie

Diese Richtlinie ist eine Zeichenfolge, die die Richtlinienanweisungen enthält, die Ihre Inhaltssicherheitsrichtlinie beschreiben. Sie können beispielsweise die folgenden Zeilen zu Ihrer .htaccess-Datei hinzufügen, um CSP zu implementieren.

 <IfModule mod_headers.c>
Header-Set Content-Security-Policy „default-src https: ‚unsafe-eval‘ ‚unsafe-inline‘ ‚self‘; object-src ‚self‘; font-src https: data: ‚self‘ http:fonts.googleapis. com themes.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http:fonts.googleapis.com"
</IfModule>

Wenn Sie CSP auf einer WordPress-Website erzwingen, sollten Sie beachten, dass WordPress „unsafe-inline“ und „unsafe-eval“ benötigt, um ordnungsgemäß zu funktionieren. Die obige Konfiguration ist ein guter Ausgangspunkt für die meisten WordPress-Websites. Allerdings birgt die Verwendung der oben genannten Konfiguration Risiken, wenn nicht genau verstanden wird, was die einzelnen Abschnitte bedeuten. Hier ist eine Aufschlüsselung der einzelnen Richtlinien:

• default-src – Diese Direktive legt die Standardrichtlinie für alle Arten von Ressourcen fest, sofern sie nicht durch andere Direktiven überschrieben werden.In diesem Fall ermöglicht es das Laden von Ressourcen vom gleichen Ursprung („self“) sowie von HTTPS-Quellen und von Skripten, die „unsafe-eval“ oder „unsafe-inline“ verwenden.
• object-src – Diese Direktive schränkt die Objekttypen ein, die in eine Seite eingebettet werden können, z. B. Flash- oder Java-Applets.Hier können Objekte nur vom gleichen Ursprung („self“) geladen werden.
• font-src – Diese Direktive schränkt die Quellen ein, aus denen Schriftarten geladen werden können.Hier können Schriftarten aus HTTPS-Quellen, dem Daten-URI-Schema und vom gleichen Ursprung („self“) oder aus HTTP-Quellen von Google Fonts und Google User Content geladen werden.
• connect-src – Diese Direktive schränkt die Quellen ein, die für Netzwerkanfragen verwendet werden können, wie zum Beispiel AJAX-Anfragen oder WebSockets.Hier können Verbindungen nur über HTTPS oder WebSockets und vom gleichen Ursprung („self“) hergestellt werden.
• img-src – Diese Direktive schränkt die Quellen ein, aus denen Bilder geladen werden können.Hier ermöglicht es das Laden von Bildern aus HTTPS-Quellen, dem Daten-URI-Schema und vom gleichen Ursprung („self“) oder aus HTTP-Quellen von Gravatar.
• worker-src – Diese Direktive schränkt die Quellen ein, aus denen Web-Worker geladen werden können.Hier können Worker nur aus dem Blob-URI-Schema, HTTPS-Quellen und aus Skripten geladen werden, die „unsafe-eval“ oder „unsafe-inline“ verwenden.
• media-src – Diese Direktive schränkt die Quellen ein, aus denen Medienressourcen geladen werden können, z. B. Audio oder Video.Hier können Medien nur von HTTPS-Quellen, dem Blob-URI-Schema und vom gleichen Ursprung („self“) geladen werden.
• style-src – Diese Direktive schränkt die Quellen ein, aus denen Stylesheets geladen werden können.Hier ermöglicht es das Laden von Stilen aus HTTPS-Quellen und aus Skripten, die „unsafe-eval“ oder „unsafe-inline“ verwenden, sowie aus demselben Ursprung („self“) und aus HTTP-Quellen von Google Fonts.

Wenn Sie den CSP-Header mit Ihrer WordPress-Instanz verwenden, ist es wichtig zu beachten, dass eineunsachgemäße Anwendung der CSP-Header das WordPress-Admin-Dashboard beschädigt, da bestimmte Plugins und Dienste möglicherweise auf JavaScript von Drittanbietern angewiesen sind.

Um dies zu beheben, müssen Sie jede Sicherheitsregel manuell zu Ihrer Header-Datei hinzufügen. Eine alternative, aber weniger sichere Möglichkeit besteht darin, den CSP-Header in Ihrem Admin-Dashboard zu deaktivieren. Hier ist zum Beispiel, was wir auf Servebolt.com tun :

 Header-Set X-Frame-Optionen SAMEORIGIN
Header-Set Referrer-Policy strict-origin-when-cross-origin
Header-Set X-XSS-Protection „1; mode=block“
<Wenn "%{REQUEST_URI} !~ /wp-admin/">
# Nur Header hinzufügen, wenn kein Admin-Bildschirm
Header setzt immer Content-Security-Policy "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.intercomcdn.com cdn.firstpromoter.com servobolt.containers .piwik.pro *.intercom.io cdn.getreplybox.com platform.twitter.com v0.wordpress.com cdn.jsdelivr.net Servebolt.piwik.pro ; media-src 'self' *.intercomcdn.com Daten: ; img -src 'self' 'unsafe-inline' *.intercom.io *.intercomcdn.com *.intercomassets.com Daten: raskesider.raskesider.no *.servebolt.com secure.gravatar.com Servebolt.piwik.pro ; connect- src 'self' ws: nexus-websocket-a.intercom.io *.piwik.pro Servebolt.piwik.pro *.intercom.io ; Font-src 'self' *.intercomcdn.com Daten: ; Frame-src 'self ' app.getreplybox.com platform.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com *.intercom.io; frame-ancestors 'self' *.servebolt. com;manifest-src 'self' ;"
</Wenn>

Wenn Sie CSP auf Ihrer Website erzwingen, sollten Sie beachten, dass Ihre Entwicklungsumgebung möglicherweise beschädigt wird, wenn Sie kein HTTPS verwenden. Wenn Sie nicht sicher sind, wie Sie eine Richtlinie für Ihre Site generieren, sollten Sie ein grafisches Tool wie ValidBot – CSP Wizard oder Report URI: CSP Generator verwenden .

7. Permissions-Policy-Header

Die Berechtigungsrichtlinie bietet Entwicklern Mechanismen, mit denen sie explizit angeben können, welche Funktionen auf einer Website implementiert werden können und welche nicht .Es verwaltet die Berechtigungen, die die Website benötigt. Dieser Header wird verwendet, um die Funktionen einer Website einzuschränken, um bestimmte Sicherheits- und Datenschutzrisiken zu verhindern, wie z. B. den Missbrauch von Javascript-APIs, die Verfolgung von Benutzern und die Ausführung von infiziertem Code.

Mit der Berechtigungsrichtlinie kann ein Server festlegen, ob eine Funktion in einem bestimmten Dokument verwendet werden kann. Es verwendetZulassungslisten – eine Liste von Ursprüngen, die bestimmte vordefinierte Werte annimmt.Der Wert des Permission-Policy-Headers besteht aus einer durch Kommas getrennten Liste von Direktivennamen und deren Werten, die die verschiedenen Berechtigungen beschreiben, die eine Website benötigt.

Die allgemeine Syntax für den Permissions-Policy-Header lautet:

 Berechtigungsrichtlinie: <directive>=<allowlist>

Wenn wir beispielsweise den gesamten Zugriff auf die Geolokalisierung blockieren müssen, würden wir Folgendes tun:

 Berechtigungsrichtlinie: geolocation=()

Hier bedeutet das Symbol () eine leere Zulassungsliste. Um den Zugriff auf eine Teilmenge der Ursprünge zu ermöglichen, würden wir Folgendes tun:

 <IfModule mod_headers.c>
Header setzt immer Permissions-Policy „geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), Gyroskop=(), Magnetometer=(), Kamera=(), Mikrofon=(), Vollbild=(selbst)“
</IfModule>

Nehmen wir ein anderes Beispiel. Der folgende Header-Wert beschränkt eine Website nur auf die Ausführung von Skripts, wenn diese vom selben Ursprung wie das Hauptdokument bereitgestellt werden:

 Berechtigungsrichtlinie: script-src 'self'

Der Permissions-Policy-Header kann verwendet werden, um den herkömmlichen Content-Security-Policy-Header zu ersetzen oder zu ergänzen, der ähnliche Funktionen bietet, jedoch eine andere Syntax und weniger Abdeckung in Bezug auf Berechtigungen aufweist.Bei diesem Header handelt es sich derzeit um eine experimentelle Technologie , die nur in Google Chrome und anderen Chromium-basierten Browsern unterstützt wird.Es bietet einen leistungsfähigeren und flexibleren Mechanismus zur Steuerung von Berechtigungen, und es wird erwartet, dass seine Akzeptanz in Zukunft zunehmen wird. Wenn Sie es selbst ausprobieren möchten, können Sie mit dem Permission Policy Header Generator ganz einfach Berechtigungsrichtlinien generieren.

Hinzufügen von HTTP-Sicherheitsheadern mithilfe der .htaccess-Datei

Wir empfehlen, HTTP-Sicherheitsheader hinzuzufügen, indem Sie die .htaccess-Datei direkt bearbeiten. Dies ist eine Serverkonfigurationsdatei, die am häufigsten von Apache-Webservern verwendet wird. Durch die Bearbeitung dieser Datei stellen Sie sicher, dass die HTTP-Sicherheitsheader in WordPress auf Serverebene konfiguriert werden.

Um diese Methode verwenden zu können, benötigen Sie Zugriff aufdie .htaccess-Datei Ihrer Website. Der Zugriff ist auf Apache-Servern über einen FTP-Client möglich.Bevor Sie Änderungen vornehmen, wird dringend empfohlen, eine Sicherungskopie Ihrer aktuellen .htaccess-Datei zu erstellen.

Melden Sie sich zunächst einfach mit einem FTP-Client oder dem Dateimanager-Tool in Ihrem Hosting-Kontrollfeld bei Ihrer Site an. Suchen Sie im Stammordner Ihrer Website die.htaccess-Datei und klicken Sie mit der rechten Maustaste auf die Option „Bearbeiten“. Dadurch wird die Datei mit einem Texteditor geöffnet.Um Ihrer Site HTTPS-Sicherheitsheader hinzuzufügen, können Sie den entsprechenden Code am Ende der .htaccess-Datei hinzufügen.

Der folgende Beispielcode kann als Ausgangspunkt verwendet werden.Es legt die am häufigsten verwendeten HTTP-Sicherheitsheader mit den empfohlenen Einstellungen fest.

 <IfModule mod_headers.c>
Header-Set Strict-Transport-Security „max-age=31536000; includeSubDomains; preload“ env=HTTPS
Header-Set X-XSS-Protection „1; mode=block“
Header-Set X-Content-Type-Options „nosniff“
Header-Set X-Frame-Options DENY
Header-Set Referrer-Policy „no-referrer-when-downgrade“
Header-Set Content-Security-Policy „default-src https: ‚unsafe-eval‘ ‚unsafe-inline‘ ‚self‘; object-src ‚self‘; font-src https: data: ‚self‘ http:fonts.googleapis. com themes.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http:fonts.googleapis.com"
Header setzt immer Permissions-Policy „geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), Gyroskop=(), Magnetometer=(), Kamera=(), Mikrofon=(), Vollbild=(selbst)“
</IfModule>

Sobald Sie die obige Konfiguration zu Ihrer .htaccess-Datei hinzufügen, werden die relevanten Header auf alle Webanfragen angewendet.

Sie können überprüfen, ob die Header verwendet werden, indem Sie in den Chrome DevTools die Registerkarte „Netzwerk“ öffnen und die Antwortheader Ihrer Anfrage überprüfen.

Speichern Sie nach dem Hinzufügen des Codes Ihre Änderungen und besuchen Sie Ihre Website erneut, um sicherzustellen, dass sie wie erwartet funktioniert. Sie müssen auch beim Bearbeiten Ihrer .htaccess-Datei vorsichtig sein, da falsche Code-Header oder Tippfehler Fehler wie den 500 Internal Server Error auslösen können .

Hinzufügen von HTTP-Sicherheitsheadern in WordPress mithilfe eines Content Distribution Network (CDN)

Ein Content Delivery Network (CDN) ist eine Gruppe geografisch verteilter Server, die zwischengespeicherte Internetinhalte von einem Netzwerkstandort bereitstellen, der einem Benutzer am nächsten liegt, um die Webleistung zu verbessern. Mit beliebten CDNs wie Cloudflarekönnen Sie Ihrer Website auch HTTP-Header hinzufügen.

Nehmen wir Cloudflare als Beispiel und sehen wir, wie wir mithilfe eines CDN HTTP-Header hinzufügen können. Cloudflare bietet zusammen mit dem CDN-Dienst eine rudimentäre kostenlose Website-Firewall, die erweiterten Sicherheitsfunktionen sind jedoch hinter einer Paywall verschlossen.

Das Einrichten von Cloudflare auf Ihrer WordPress-Website ist ganz einfach. Sie können sich manuell auf der Website von Cloudflare anmelden und die Schritte auf dem Bildschirm befolgen, um es zu aktivieren. Sobald Cloudflare auf Ihrer Website aktiviert wurde, gehen Sie zur SSL/TLS-Seite im Dashboard Ihres Cloudflare-Kontos.

Anschließend müssen Sie zur Registerkarte „Edge-Zertifikate“ wechseln, den Abschnitt „HTTP Strict Transport Security (HSTS)“ suchen und auf die Option „HSTS aktivieren“ klicken. Nachdem Sie die Schaltfläche „HSTS aktivieren“ aktiviert haben, wird ein Fenster mit Anweisungen angezeigt, die Ihnen bei der Aktivierung dieser Funktion auf Ihrer Website helfen. Klicken Sie auf die Schaltfläche „Weiter“, um den Vorgang fortzusetzen. Anschließend wird die Option zum Hinzufügen von HTTP-Sicherheitsheadern angezeigt.

Von hier aus können Sie HSTS auf Ihrer Website aktivieren und HSTS auch auf Subdomains anwenden, die HTTPS verwenden. Die Verwendung dieser Methode bietet Ihrer Website einen grundlegenden Schutz mithilfe von HTTP-Sicherheitsheadern. Der Nachteil besteht jedoch darin, dass Sie bei Cloudflare derzeit keine X-Frame-Optionen hinzufügen können.

Es ist erwähnenswert, dass HSTS für Servebolt.com und alle anderen Domänen innerhalb von Cloudflare standardmäßig aktiviert ist.

Hinzufügen von HTTP-Sicherheitsheadern mithilfe eines WordPress-Plugins

Eine dritte Methode zum Hinzufügen und Konfigurieren von HTTP-Headern ist die Verwendung eines Plugins. Obwohl dies eine der einfachsten Möglichkeiten ist, Ihrer WordPress-Website HTTP-Sicherheitsheader hinzuzufügen, ist sie in der Regel etwas weniger effektiv als die manuelle Konfiguration der Header.

Möglicherweise haben Sie bereits an anderer Stelle gelesen, dass viele Sicherheits-Plugins die Möglichkeit bieten, Sicherheitsheader hinzuzufügen. Wir raten jedoch davon ab, ein Sicherheits-Plugin zu verwenden. Lesen Sie unseren Artikel über WordPress-Sicherheits-Plugins, um zu verstehen, warum und welche Bedenken bei der Verwendung dieser Plugins bestehen.

In diesem Abschnitt können Sie verschiedene Header aktivieren oder deaktivieren und verschiedene Parameter für sie festlegen. Die genauen Header, die Sie aktivieren können, variieren je nach Plugin Ihrer Wahl, aber die gängigen Header wie X-XSS-Protection, X-Content-Type-Options, X-Frame-Options und Strict-Transport-Security werden von abgedeckt die meisten Plugins.

So überprüfen Sie HTTP-Sicherheitsheader auf Ihrer Website

Nachdem Sie die HTTP-Sicherheitsheader zu Ihrer WordPress-Website hinzugefügt haben, müssen Sie sicherstellen, dass sie richtig konfiguriert sind und wie erwartet funktionieren. Für die Durchführung eines Tests können Sie eines der zahlreichen kostenlosen Tools im Internet nutzen. Wir empfehlen die Verwendung von Security Headers oder SSL Labs . Beide bieten Ihnen eine einfache Möglichkeit, Ihre Konfiguration zu testen und zu überprüfen, ob alle Sicherheitsheader ordnungsgemäß funktionieren.

Diese Tools bewerten die Sicherheitsheader Ihrer Website und stellen Ihnen einen detaillierten Bericht zur Verfügung. Sie sagen Ihnen auch, welche HTTP-Sicherheitsheader Ihre Website sendet und welche nicht. Anschließend erhält Ihre Website eine Note von A+ bis F, zusammen mit einer Erläuterung, wie diese Note ermittelt wurde.

Als wir beispielsweise die Website von Vogue testeten , stellten wir fest, dass ihr viele wichtige HTTP-Header fehlten, sodass sie nur die Note C erhielt.

Und wie Sie beim Testen unserer eigenen Website erwarten können, erhält sie die Note A+.

Abschluss

Es steht außer Frage, dass die Implementierung von HTTP-Headern ein wesentlicher Schritt zur Sicherung Ihrer Website ist. Nachdem Sie erfolgreich HTTP-Header zu Ihrer Website hinzugefügt haben, sollten Sie die folgenden zusätzlichen Schritte berücksichtigen:

1. Auf Schwachstellen testen : Es ist wichtig, Ihre Website auf häufige Sicherheitslücken wie Cross-Site-Scripting (CSS) und Cross-Site-Request-Forgery (CSRF) zu testen.Zu diesem Zweck können Sie Tools wie OWASP ZAP und Burp Suite verwenden .
2. Überwachen Sie Änderungen : Sie müssen die Header regelmäßig auf unerwartete Änderungen überwachen, da dies normalerweise darauf hindeutet, dass versucht wurde, eine Schwachstelle auszunutzen.
3. Aktualisieren Sie die Header : Wenn neue Bedrohungen auftauchen, ist es wichtig, über die neuesten Sicherheitspraktiken auf dem Laufenden zu bleiben und Ihre Header entsprechend zu aktualisieren.

Sind Sie an Managed Hosting interessiert, das empirisch schneller ist?

Probieren Sie unseren Ansatz zum WordPress-Hosting aus – der Einstieg ist kostenlos und zu den Vorteilen gehören:

• Skalierbarkeit: In den realen Benutzer-Workload-Tests lieferte Servebolt durchschnittliche Reaktionszeiten von 65 ms, 4,9-mal schnellere Reaktionszeiten als die zweitbeste Lösung.
• Die schnellsten globalen Ladezeiten: Mit durchschnittlichen Seitenladezeiten von 1,26 Sekunden stehen wir an der Spitze der Liste der globalen WebPageTest-Ergebnisse.
• Die schnellste Rechengeschwindigkeit: Servebolt-Server bieten bisher unerreichte Datenbankgeschwindigkeiten, verarbeiten 2,44-mal mehr Abfragen pro Sekunde als der Durchschnitt und führen PHP 2,6-mal schneller aus als der Zweitbeste!
• Perfekte Sicherheit und Verfügbarkeit: Mit 100 % Verfügbarkeit auf allen Monitoren und der Bewertung A+ für unsere SSL-Implementierung können Sie sicher sein, dass Ihre Website online und sicher ist.

Kurz gesagt: Indem wir Ihnen das Hosting abnehmen, können Sie die Sicherheit, Geschwindigkeit und Leistung Ihrer Website einfacher verbessern. Melden Sie sich bei Servebolt an, um uns auf die Probe zu stellen.