Basic Policies – Grundlegende Richtlinien

Der Default-Wert, der sowohl HTTP als auch HTTPS abdeckt, ist oft die empfohlene Einstellung. Hier sind einige Gründe dafür:

1. Ganzheitlicher Schutz: Wenn NinjaFirewall für HTTP und HTTPS aktiviert ist, schützt es deine Website unabhängig davon, wie Besucher darauf zugreifen. Das bedeutet, dass egal ob die Verbindung unverschlüsselt (HTTP) oder verschlüsselt (HTTPS) ist, die Sicherheit gewährleistet ist.
   • Wenn Besucher auf verschiedene Teile der Website über verschiedene Protokolle zugreifen, kann die Aktivierung beider Optionen die Benutzererfahrung verbessern, indem ein einheitlicher Schutz geboten wird, ohne dass Besucher sich Gedanken über die Art der Verbindung machen müssen.
2. Umfassende Abdeckung: Einige Teile deiner Website könnten über HTTP und andere über HTTPS bedient werden. Indem du NinjaFirewall für beide aktivierst, gewährleistest du, dass sämtlicher Traffic abgedeckt ist.
3. Konsistenz im Schutz: Die Konfiguration von Sicherheitsmaßnahmen für beide Protokolle (HTTP und HTTPS) gewährleistet eine konsistente Sicherheitspolitik. Das hilft dabei, mögliche Schwachstellen in jedem Teil der Website zu minimieren, unabhängig davon, wie die Verbindung hergestellt wird.

Es ist wichtig zu verstehen, dass diese Einstellungen je nach den individuellen Anforderungen einer Website und dem spezifischen Sicherheitsbedarf variieren können. Im Allgemeinen bietet die Aktivierung für beide Protokolle jedoch eine umfassende und konsistente Sicherheitsabdeckung.

Die weiteren Einstellungen sind sehr individuell und sind recht selbsterklärend.

Insbesondere sind aber die Hinweise zur REST-API und API zu berücksichtigen. Die vorgegebenen Grundeinstellungen sind generell eine gute Wahl.

Die REST-API und die XML-RPC-API sind beide Methoden für die Kommunikation zwischen verschiedenen Systemen oder Diensten und deiner WordPress-Website. Beide APIs ermöglichen es anderen Diensten oder Anwendungen, mit deiner Website zu interagieren, Daten abzurufen oder zu übertragen.

Wenn det Zugriff auf die REST-API deaktivierz wird, könnten bestimmte Funktionen oder Plug-ins auf der Website, die diese API nutzen, beeinträchtigt werden. Das Gleiche gilt auch für die XML-RPC-API. Beide APIs spielen eine wichtige Rolle für verschiedene Plugins und Funktionen, einschließlich des Gutenberg-Editors, Jetpack, Contact Form 7 und anderen.

Die Entscheidung, ob diese APIs aktiviert oder deaktiviert, hängt von den Sicherheitsanforderungen und den Funktionen ab, die auf der Website erforderlich sind. Es ist wichtig zu beachten, dass das Deaktivieren dieser APIs einige Funktionen beeinträchtigen kann, die auf ihrer Verwendung basieren.

Intermediate Policies – Mittlere Richtlinien

Hier geht es um die:

• HTTP GET variable,
• HTTP POST variable,
• HTTP REQUEST variable,
• Cookies,
• HTTP_USER_AGENT server variable,
• HTTP_REFERER server variable und
• IP

HTTP GET variable

Scan GET Variable" und "Sanitize GET Variable" sind Sicherheitsfunktionen und dienen dazu, Anfragen und Daten, die über die GET-Methode gesendet werden, zu überwachen und zu schützen.

1. Scan GET Variable: Diese Funktion ermöglicht dem Sicherheits-Plug-in das Überwachen und Analysieren von Daten, die über GET-Parameter an die Website gesendet werden. GET-Variablen sind Teil der URL und können von Benutzern eingefügt werden. Das Plug-in scannt diese Variablen auf mögliche Anzeichen von Angriffen, schädlichem Code oder verdächtigen Inhalten.
2. Sanitize GET Variable: "Sanitizing" bezieht sich auf den Prozess des Reinigens oder Filterns von Daten, um sicherzustellen, dass sie frei von schädlichem Code oder potenziell gefährlichen Inhalten sind. Diese Funktion filtert und bereinigt die über GET-Parameter gesendeten Daten. Sie entfernt potenziell gefährlichen Code oder versucht, schädliche Eingaben zu neutralisieren, um Sicherheitsrisiken zu minimieren.

Es wird empfohlen, diese Funktionen zu aktivieren, um die Sicherheit der Website zu erhöhen, insbesondere wenn die Website öffentlich zugänglich ist und Benutzer über Formulare oder URLs interagieren können. Durch die Überwachung und Bereinigung von GET-Variablen können potenzielle Sicherheitslücken minimiert und Angriffe wie Injection-Angriffe (z. B. SQL-Injection) oder Cross-Site-Scripting (XSS) abgewehrt werden.

Es ist jedoch wichtig zu beachten, dass die Aktivierung dieser Funktionen möglicherweise dazu führen kann, dass einige spezifische Funktionen oder Anwendungen auf der Website nicht wie erwartet funktionieren. Es ist ratsam, die Auswirkungen auf die Website zu überwachen, nachdem diese Funktionen aktiviert wurden.

HTTP POST variable

HTTP POST-Variablen sind Daten, die über das POST-Verfahren an eine Webseite oder Anwendung gesendet werden. Im Gegensatz zu GET-Variablen, die in der URL sichtbar sind, werden POST-Variablen über das HTTP-Body gesendet und sind daher nicht direkt sichtbar.

Die Funktionen "Scan POST Variable" und "Sanitize POST Variable" in einem Security-Plug-in dienen ähnlichen Zwecken wie bei den GET-Variablen:

1. Scan POST Variable: Diese Funktion überwacht und analysiert Daten, die über POST-Requests an die Webseite gesendet werden. POST-Variablen können genutzt werden, um Daten von Formularen oder anderen interaktiven Elementen zu übertragen. Das Plug-in scannt diese Variablen auf potenzielle Anzeichen von Angriffen oder schädlichem Code.
   • Das Aktivieren der Funktionen für Scan POST-Variable ist ebenfalls empfehlenswert, um Sicherheitsrisiken zu minimieren. POST-Daten können sensible Informationen enthalten und werden oft für Interaktionen wie das Einreichen von Formularen verwendet.
2. Sanitize POST Variable: Ähnlich wie bei der "Sanitize GET Variable"-Funktion reinigt und filtert diese Funktion die über POST-Variablen gesendeten Daten. Sie entfernt potenziell gefährlichen Code oder neutralisiert schädliche Eingaben, um die Sicherheit der Webseite zu verbessern. "Aktivieren Sie diese Option nur, wenn Sie wissen, was Sie tun!"
   • Es ist wichtig zu beachten, dass diese Sicherheitsmaßnahmen die Funktionalität von bestimmten Formularen oder Interaktionen beeinträchtigen können. Es ist ratsam, nach der Aktivierung dieser Funktionen die Funktionalität der Webseite zu überwachen und gegebenenfalls Anpassungen vorzunehmen.

Die Überwachung und Bereinigung dieser Daten können helfen, potenzielle Angriffe wie Injection-Angriffe oder Cross-Site-Scripting abzuwehren und die Sicherheit der Webseite zu stärken.

HTTP REQUEST variable

Diese Option führt eine Datenbereinigung durch, um schädlichen Code oder potenziell gefährliche Eingaben zu entfernen. Das Problem dabei ist, dass eine zu strenge Bereinigung auch legitime Daten verändern oder entfernen könnte, was sich auf die Funktionalität der Webseite auswirken kann.

• Sanitise REQUEST variable kann die "Sanitize"-Funktion für legitime Eingaben zu restriktiv sein und dazu führen, dass bestimmte Formulare oder Funktionen nicht mehr wie erwartet funktionieren.

Es wird empfohlen, diese Option mit Vorsicht zu aktivieren und vorherige Sicherungskopien deiner Webseite zu erstellen. Außerdem ist es ratsam, die Webseite nach der Aktivierung dieser Option gründlich zu überprüfen, um sicherzustellen, dass keine wesentlichen Funktionen beeinträchtigt wurden und dass die Webseite weiterhin wie erwartet funktioniert. Bei Unsicherheit oder nicht genauem verständnis, wie diese Funktion die Webseite beeinflussen könnte, ist es möglicherweise besser, diese Option zunächst nicht zu aktivieren oder Hilfe von Experten in Anspruch zu nehmen.

Cookies

"Scan Cookies" und "Sanitize Cookies" sind Sicherheitsfunktionen, die sich auf die Überwachung und Bereinigung von Cookies beziehen, die von der Webseite gesetzt oder empfangen werden.

1. Scan Cookies: Diese Funktion überwacht die Cookies, die von der Webseite gesetzt oder empfangen werden. Cookies sind kleine Datenstücke, die von Webseiten im Browser des Benutzers gespeichert werden. Das Plug-in scannt diese Cookies auf potenzielle Anzeichen von Angriffen oder schädlichem Inhalt. Dies ermöglicht die Erkennung verdächtiger oder möglicherweise gefährlicher Cookies, die möglicherweise Sicherheitsrisiken darstellen könnten.
2. Sanitize Cookies: Ähnlich wie bei der "Sanitize Variable"-Funktion für GET- und POST-Variablen reinigt diese Funktion Cookies, um sicherzustellen, dass sie frei von schädlichem Code oder potenziell gefährlichen Inhalten sind. Sie filtert und bereinigt die Cookies, bevor sie auf dem Browser des Benutzers gespeichert werden. Dies hilft, potenzielle Sicherheitslücken zu minimieren und schädliche oder manipulierte Cookies zu neutralisieren.

Diese Funktionen sind wichtig, um die Sicherheit der Webseite zu erhöhen, insbesondere wenn Cookies von Drittanbietern oder anderen Quellen stammen können. Die Überwachung und Bereinigung von Cookies können dabei helfen, mögliche Angriffsvektoren wie Cross-Site-Scripting (XSS) oder böswillige Cookie-Manipulation zu verhindern.

Es ist jedoch wichtig zu beachten, dass das Aktivieren dieser Funktionen die Funktionalität bestimmter Cookies beeinträchtigen oder dazu führen kann, dass legitime Cookies fälschlicherweise als verdächtig markiert und entfernt werden. Dies kann sich auf die Funktionalität und Benutzererfahrung der Webseite auswirken. Es ist daher ratsam, die Auswirkungen dieser Funktionen zu überwachen, nachdem sie aktiviert wurden, und sicherzustellen, dass keine wichtigen Funktionen beeinträchtigt wurden.

HTTP_USER_AGENT server variable

Die Servervariable HTTP_USER_AGENT enthält Informationen zum Benutzer-Agenten, der den aktuellen HTTP-Request an den Server sendet. Diese Informationen enthalten normalerweise Details zum verwendeten Browser, Betriebssystem und möglicherweise anderen relevanten Details, die vom Client gesendet werden.

1. Scan HTTP_USER_AGENT: Diese Funktion überwacht und analysiert die HTTP_USER_AGENT-Header in den HTTP-Requests, die an den Server gesendet werden. Dies ermöglicht die Überprüfung auf verdächtige oder ungewöhnliche Benutzer-Agenten, die möglicherweise auf Bots, Scanner oder andere böswillige Software hinweisen.
2. Sanitise HTTP_USER_AGENT: Ähnlich wie bei anderen "Sanitize"-Funktionen bereinigt diese Option die HTTP_USER_AGENT-Informationen. Sie filtert potenziell gefährliche oder schädliche Inhalte aus dem HTTP_USER_AGENT-Header heraus, um Sicherheitsrisiken zu minimieren.
3. Block suspicious bots/scanners /: Diese Funktion blockiert oder sperrt verdächtige Benutzer-Agenten, die als Bots, Scanner oder potenziell schädliche Software identifiziert werden. Sie hilft dabei, den Zugriff solcher Bots oder Scanner auf die Webseite zu unterbinden, um die Sicherheit zu verbessern und mögliche Angriffsvektoren zu reduzieren.

Diese Funktionen sind wichtige Sicherheitsmaßnahmen, um verdächtige Aktivitäten, die durch abnormale oder schädliche Benutzer-Agenten verursacht werden könnten, zu überwachen, zu bereinigen und zu blockieren. Es ist jedoch wichtig zu beachten, dass einige legitime Anwendungen oder Dienste auch spezifische Benutzer-Agenten verwenden können, die möglicherweise fälschlicherweise als verdächtig eingestuft werden könnten.

Es ist ratsam, nach der Aktivierung dieser Funktionen das Verhalten der Webseite zu überwachen, um sicherzustellen, dass keine legitimen Benutzer-Agenten oder Dienste fälschlicherweise blockiert oder beeinträchtigt werden. Gegebenenfalls können Ausnahmen oder Whitelists für legitime Benutzer-Agenten eingerichtet werden, um sicherzustellen, dass diese ordnungsgemäß funktionieren können.

HTTP_REFERER server variable

Die HTTP_REFERER-Servervariable gibt Informationen darüber, von welcher URL aus der Benutzer auf die aktuelle Seite gelangt ist. Diese Variable enthält normalerweise die URL der vorherigen Webseite, von der der Benutzer einen Link oder eine Anfrage verfolgt hat.

1. Scan HTTP_REFERER: Diese Funktion überwacht die HTTP_REFERER-Header in den HTTP-Requests, die an den Server gesendet werden. Sie ermöglicht die Überprüfung auf verdächtige oder ungewöhnliche Referer-Informationen, die möglicherweise auf bestimmte Angriffe wie CSRF (Cross-Site Request Forgery) oder andere böswillige Aktivitäten hinweisen könnten.
2. Sanitize HTTP_REFERER: Ähnlich wie bei anderen "Sanitize"-Funktionen reinigt diese Option die HTTP_REFERER-Informationen. Sie filtert potenziell gefährliche oder schädliche Inhalte aus dem HTTP_REFERER-Header heraus, um Sicherheitsrisiken zu minimieren.

Diese Funktionen sind wichtige Sicherheitsmaßnahmen, um verdächtige Aktivitäten oder mögliche Angriffsvektoren, die durch Referer-Informationen verursacht werden könnten, zu überwachen, zu filtern und zu bereinigen. Einige Sicherheitsbedrohungen wie CSRF-Angriffe können Informationen im HTTP_REFERER-Header ausnutzen, um böswillige Aktionen auszuführen.

Es ist jedoch wichtig zu beachten, dass einige legitime Anwendungen oder Dienste möglicherweise Referer-Informationen verwenden, die möglicherweise fälschlicherweise als verdächtig eingestuft werden könnten. Daher sollte nach der Aktivierung dieser Funktionen das Verhalten der Webseite überwacht werden, um sicherzustellen, dass keine legitimen Referer blockiert oder beeinträchtigt werden. Gegebenenfalls können Ausnahmen oder Whitelists für legitime Referer eingerichtet werden, um sicherzustellen, dass diese ordnungsgemäß funktionieren können.

3. Block POST requests that do not have an HTTP_REFERER header: Die HTTP_REFERER-Header-Variable wird normalerweise von einem Browser gesendet und gibt die URL der Seite an, von der aus die aktuelle Anfrage stammt. Einige Anwendungen und Skripte verwenden diesen Header, um die Herkunft von Anfragen zu überprüfen und deren Legitimität zu bestätigen.
   • Die Option "Block POST requests that do not have an HTTP_REFERER header" blockiert POST-Anfragen, die keinen HTTP_REFERER-Header enthalten. Das bedeutet, dass Anfragen, die von einer Seite ohne diesen Header gesendet werden, blockiert werden. Dies kann bestimmte Arten von Anfragen einschränken, die keine oder eine leere HTTP_REFERER-Header-Variable enthalten.

Es wird empfohlen, diese Option deaktiviert zu lassen, wenn Skripte oder Anwendungen sind, die keine HTTP_REFERER-Header-Variable in ihren Anfragen senden. Einige bekannte Dienste wie PayPal IPN (Instant Payment Notification) oder WordPress WP-Cron könnten solche Anfragen senden. Wenn diese Option aktiviert ist, könnten legitime Anfragen dieser Dienste blockiert werden, was zu Funktionsstörungen oder Problemen führen könnte.

IP

Diese Sicherheitsmaßnahmen beziehen sich auf die Überwachung und Blockierung von HTTP-Anfragen und Datenverkehr, die bestimmte IP-bezogene Sicherheitsrisiken darstellen könnten:

1. Block localhost IP in GET/POST request / Lokale Host-IP in GET/POST-Anfrage blockieren: Diese Funktion blockiert HTTP-Anfragen, bei denen die lokale Host-IP-Adresse in den GET- oder POST-Anfragen enthalten ist. Dies dient dazu, Anfragen abzufangen, die von der eigenen Server-IP stammen oder darauf zielen, was oft auf potenziell schädliche oder nicht autorisierte Anfragen hinweisen könnte.
2. Block HTTP requests with an IP in the HTTP_HOST header / Blockieren von HTTP-Anfragen mit einer IP im HTTP_HOST-Header: Der HTTP_HOST-Header gibt normalerweise den Hostnamen oder die IP-Adresse der angeforderten Ressource an. Das Blockieren von Anfragen mit einer IP-Adresse im HTTP_HOST-Header könnte darauf abzielen, Anfragen zu blockieren, die möglicherweise auf spezifische Sicherheitsprobleme oder Angriffsvektoren hinweisen.
3. Scan traffic coming from localhost and private IP address spaces / Scannen des Datenverkehrs von lokalen Host- und privaten IP-Adressräumen: Diese Funktion überwacht und analysiert den Datenverkehr, der von lokalen Hosts oder aus privaten IP-Adressbereichen stammt. Lokale Hosts sind normalerweise der eigene Server oder interne Netzwerke. Das Scannen dieses Datenverkehrs kann dazu beitragen, potenziell schädliche oder nicht autorisierte Aktivitäten innerhalb des lokalen Netzwerks zu erkennen und zu blockieren.

Diese Sicherheitsfunktionen zielen darauf ab, bestimmte IP-bezogene Sicherheitsrisiken zu minimieren, indem potenziell verdächtige Anfragen oder Datenverkehr, die auf spezifische Muster oder Bedingungen hinweisen, erkannt und blockiert werden. Sie sind wichtige Maßnahmen, um die Sicherheit des Servers und der Webanwendung zu erhöhen.

Es ist jedoch wichtig zu beachten, dass solche Maßnahmen gelegentlich legitime Anfragen oder Datenverkehr blockieren könnten, insbesondere wenn bestimmte Konfigurationen oder spezifische Netzwerkkonfigurationen vorhanden sind. Daher ist eine sorgfältige Überwachung und gegebenenfalls das Hinzufügen von Ausnahmen oder Whitelists für legitime IP-Adressen erforderlich, um sicherzustellen, dass wichtige Funktionalitäten nicht beeinträchtigt werden.

Advanced Policies – Erweiterte Richtlinien

In diesem Teil werden die erweiterten Richtlinien behandelt. Vorsicht ist zu walten, wenn Änderungen vorgenommen werden, da dies mehr schaden als nützen könnte . Wenn Sie sich nicht sicher sind, belassen Sie die Standardwerte.

Somit ist das Folgende nur als Überblick zu betrachten und sich der jeweilign Links erweiterten Information zu bedienen!

• HTTP response headers
• PHP
• Various / Verschiedenes

HTTP response headers – HTTP-Antwortheader

• Set X-Content-Type-Options to protect against MIME type confusion attacks geht es darum, eine Sicherheitsmaßnahme zu aktivieren, die vor Angriffen durch MIME-Typ-Verwirrung schützt. Diese Einstellung hilft dabei, die Sicherheit der Webseite zu erhöhen, indem sie sicherstellt, dass der Browser den vom Server bereitgestellten MIME-Typ nicht ändert. Es ist eine präventive Maßnahme, um mögliche Angriffe zu minimieren, indem die Verwirrung der MIME-Typen verhindert wird. Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Set X-Frame-Options to protect against clickjacking attempts ist eine Sicherheitseinstellung, die deine Webseite vor Clickjacking-Versuchen schützt. Clickjacking ist eine Art von Angriff, bei dem ein schädlicher Akteur Inhalte einer Webseite in einem unsichtbaren Rahmen versteckt, um den Benutzer dazu zu bringen, ungewollte Aktionen auszuführen, indem er auf scheinbar harmlose Elemente klickt. Durch das Aktivieren der X-Frame-Options kannst du verhindern, dass deine Webseite in Frames oder iframes auf anderen Domains eingebettet wird, was potenzielle Clickjacking-Angriffe abschwächt. Es ist eine wichtige Sicherheitsmaßnahme, um die Integrität deiner Webseite zu schützen.
  • Wenn diese Option auf DENY gesetzt wird, können einige Funktionen des Blogs, seiner Themes oder Plugins beeinträchtigt werden.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Set X-XSS-Protection: Der X-XSS-Protection-Header war früher ein gängiger Schutzmechanismus gegen XSS-Angriffe. Allerdings haben die meisten modernen Browser die Unterstützung für diesen Header eingestellt, da er als ineffektiv angesehen wird. Die Verwendung der Content-Security-Policy (CSP) gilt heute als empfohlene Methode gilt, um XSS-Angriffe zu verhindern. CSP bietet umfassendere Möglichkeiten zur Steuerung und Absicherung der Webseite gegen XSS-Angriffe im Vergleich zum veralteten X-XSS-Protection-Header.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Force SameSite flag on all cookies to mitigate CSRF attacks. Das Setzen des "SameSite"-Flags auf alle Cookies ist eine Maßnahme zur Minimierung von CSRF (Cross-Site Request Forgery) Angriffen. Dieses Flag wird verwendet, um festzulegen, wie Cookies in Browsern zwischen verschiedenen Seiten und Domains geteilt werden. Wenn das "SameSite"-Flag auf "Strict" oder "Lax" gesetzt ist, werden Cookies nur für Anfragen gesendet, die von derselben Ursprungswebsite stammen, was die Wahrscheinlichkeit von böswilligen Anfragen von anderen Seiten aus verringert. Dies trägt dazu bei, die Sicherheit der Webseite gegenüber CSRF-Angriffen zu erhöhen.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Force HttpOnly flag on all cookies to mitigate XSS attacks: Das Setzen des "HttpOnly"-Flags auf Cookies ist eine Sicherheitsmaßnahme, die bei der Abwehr von XSS (Cross-Site Scripting) Angriffen hilft. Indem das "HttpOnly"-Flag aktiviert wird, wird verhindert, dass JavaScript über das Document Object Model (DOM) auf Cookies zugreift. Dies reduziert das Risiko, dass Angreifer Cookies stehlen und so sensible Daten wie Session-IDs erhalten können.
  • Wenn PHP-Skripte Cookies verwendet werden, auf die über JavaScript zugegriffen werden muss, sollte diese Option nicht aktiviert sein.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Set Strict-Transport-Security (HSTS) to enforce secure connections to the server: Die "Strict-Transport-Security" (HSTS) Richtlinie ist eine Sicherheitsmaßnahme, die sicherstellt, dass eine Website nur über eine verschlüsselte Verbindung (HTTPS) aufgerufen wird. Indem HSTS aktiviert wird, wird Browsern mitgeteilt, dass sie immer eine verschlüsselte Verbindung verwenden sollen, wenn sie auf diese Website zugreifen. Dies hilft, Man-in-the-Middle-Angriffe zu verhindern und die Sicherheit der Verbindung zwischen Browser und Server zu erhöhen.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Set Content-Security-Policy for the website frontend legt fest, welche Ressourcen auf einer Website geladen werden dürfen. Es ist eine Sicherheitsmaßnahme, die das Risiko von Cross-Site-Scripting-Angriffen (XSS) verringert, indem sie steuert, welche Ressourcen (wie Skripte, Stylesheets, Bilder usw.) von einer Website geladen werden können. Indem bestimmte Sicherheitsrichtlinien definiert werden, kann die CSP das Risiko von böswilligen Skripten reduzieren, die von anderen Domains oder Quellen auf einer Seite ausgeführt werden können.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Set Content-Security-Policy for the WordPress admin dashboard: Die Content-Security-Policy (CSP) kann auch für das WordPress-Admin-Dashboard konfiguriert werden, um die Sicherheit zu verbessern. Sie legt fest, welche Ressourcen und Inhalte auf der Admin-Oberfläche geladen werden dürfen. Indem sie bestimmte Richtlinien für Skripte, Stylesheets, Bilder und andere Ressourcen definiert, kann die CSP das Risiko von Cross-Site-Scripting-Angriffen verringern und die Sicherheit des Admin-Bereichs verbessern.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
• Set Referrer-Policy (Chrome, Opera and Firefox browsers): Die Referrer-Policy-Header setzen Richtlinien für den Referrer, der von einem Browser gesendet wird, wenn ein Benutzer auf eine Seite zugreift. Es legt fest, wie viele Informationen über die ursprüngliche Seite an die aufgerufene Seite weitergegeben werden. Diese Einstellung hilft, die Privatsphäre der Benutzer zu schützen und bestimmte Informationen zu limitieren oder zu verbergen, die an andere Seiten weitergegeben werden könnten.
  • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.

PHP