Eine WordPress-Website ist nur so stark wie ihr schwächstes Plugin, Konto oder Backup. Der WordPress-Kern erhält regelmäßig Sicherheitsupdates; was Sie hinzufügen und wie Sie die Website betreiben, liegt bei Ihnen. Diese Checkliste umfasst die wichtigsten Maßnahmen, grob in der Reihenfolge, in der wir sie umsetzen würden.
1. Kern, Plugins und Themes aktuell halten
Automatische Hintergrund-Updates für den Kern gibt es seit WordPress 3.7; standardmäßig umfassen sie Minor-Releases. Seit WordPress 5.5 können Sie automatische Updates außerdem für jedes Plugin und Theme im Adminbereich einschalten.
- Aktivieren Sie automatische Updates für Plugins seriöser Entwickler und prüfen Sie die übrigen wöchentlich.
- Automatische Updates sind auf WP-Cron angewiesen. Prüfen Sie unter Werkzeuge > Website-Zustand, ob Fehler gemeldet werden, denn bei einem defekten Cron bleiben Updates unbemerkt aus.
- Stellen Sie sicher, dass Sie Updates zurückrollen können, bevor Sie sich auf automatische Updates verlassen. Das empfiehlt auch die WordPress-Dokumentation.
2. Verwaiste und ungenutzte Plugins entfernen
Der Härtungsleitfaden von WordPress ist eindeutig: Halten Sie Plugins aktuell und löschen Sie die, die Sie nicht nutzen. Deaktivieren reicht nicht, denn der Code bleibt auf dem Server.
Das Plugin-Verzeichnis auf WordPress.org liefert Ihnen zwei Warnzeichen:
- Einen gelben Hinweis, dass ein Plugin „nicht mit den letzten 3 Hauptversionen von WordPress getestet“ wurde.
- Einen roten Hinweis, dass ein Plugin geschlossen wurde und nicht mehr heruntergeladen werden kann. Nach 60 Tagen wird der Grund angezeigt, und „Sicherheitsproblem“ ist einer der aufgeführten Gründe.
Ein geschlossenes Plugin erhält über WordPress.org keine Updates mehr. Ersetzen Sie es. Installieren Sie niemals „genullte“ Kopien von Premium-Plugins und installieren Sie nur von WordPress.org oder von Anbietern, denen Sie vertrauen.
3. Administratorkonten prüfen
Listen Sie alle Konten mit der Rolle Administrator auf und entfernen Sie die, die niemand erklären kann. Mit WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredGeben Sie jeder Person ein eigenes, namentliches Konto, niemals einen gemeinsamen Login admin. Verwenden Sie die niedrigste Rolle, die für die Aufgabe genügt: Die meisten Redakteure brauchen keine Administratorrechte. Verlangen Sie starke, eindeutige Passwörter, idealerweise in einem Passwort-Manager gespeichert.
4. Zwei-Faktor-Authentifizierung aktivieren
Aktivieren Sie 2FA für jeden Administrator. Der WordPress-Kern enthält keine 2FA; Sie brauchen also ein Plugin oder einen Single-Sign-on-Anbieter, der sie erzwingt. Bevorzugen Sie Verfahren wie Sicherheitsschlüssel oder Passkeys, sofern Ihr Plugin sie unterstützt, und bewahren Sie Wiederherstellungscodes sicher auf.
5. Anmeldungen begrenzen und über XML-RPC entscheiden
Die WordPress-Dokumentation nennt wp-login.php und xmlrpc.php als häufige Ziele von Brute-Force-Angriffen. Sie empfiehlt, Anmeldeversuche am Netzwerkrand (WAF oder CDN) oder auf dem Webserver zu begrenzen. Auch ein Sicherheits-Plugin kann Anmeldungen drosseln, läuft aber in PHP; die Variante auf Serverebene hält hoher Last daher besser stand.
Wenn Sie XML-RPC nicht nutzen, deaktivieren Sie es. Manche mobilen Apps und Dienste wie Jetpack brauchen es; prüfen Sie das also vorher. Beachten Sie, dass der Filter xmlrpc_enabled nur Methoden deaktiviert, die eine Authentifizierung erfordern. Pingbacks und andere Methoden ohne Authentifizierung funktionieren weiter. Um XML-RPC vollständig abzuschalten, sperren Sie die Datei auf dem Webserver. Für nginx:
location = /xmlrpc.php {
deny all;
}6. Den integrierten Datei-Editor abschalten
Mit dem Theme- und Plugin-Editor im Dashboard kann jeder mit einer Administrator-Sitzung PHP-Code ändern. Deaktivieren Sie ihn in wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );Laut der Dokumentation zu wp-config.php geht DISALLOW_FILE_MODS weiter und blockiert auch die Installation und Aktualisierung von Plugins und Themes über das Dashboard. Verwenden Sie es nur, wenn Sie Änderungen auf anderem Weg ausrollen, etwa über Git oder WP-CLI.
7. Backups außerhalb des Servers und des Web-Roots aufbewahren
Der Härtungsleitfaden empfiehlt regelmäßige Backups von Dateien und Datenbank, mehrere Sicherungsstände und einen vertrauenswürdigen Speicherort. Schützen Sie ihre Integrität durch Verschlüsselung, festgehaltene Hashwerte oder schreibgeschützte Medien.
Daraus folgen zwei praktische Regeln. Ein Backup im Web-Root, etwa eine ZIP-Datei in wp-content, kann jeder herunterladen, der den Namen errät. Ein Backup auf demselben Server kann derselbe Angreifer löschen. Bewahren Sie mindestens eine Kopie dort auf, wo die Zugangsdaten der Website nicht hinreichen, und testen Sie eine vollständige Wiederherstellung.
8. Dateiintegrität prüfen
WP-CLI kann Ihre Dateien mit den offiziellen Prüfsummen von WordPress.org vergleichen, ohne WordPress zu laden:
wp core verify-checksums --include-root
wp plugin verify-checksums --allDer erste Befehl meldet veränderte Kerndateien, und --include-root warnt vor unerwarteten Dateien im Stammverzeichnis. Der zweite gleicht Plugins mit den Prüfsummen von WordPress.org ab und hilft daher nur bei Plugins, die dort gehostet werden. Suchen Sie außerdem nach PHP-Dateien in wp-content/uploads, wo normalerweise nur Mediendateien liegen sollten.
9. Einen Datenbankbenutzer mit minimalen Rechten verwenden
Geben Sie jeder Website eine eigene Datenbank und einen eigenen Datenbankbenutzer mit Rechten nur auf diese Datenbank. Verbinden Sie sich nie als Root-Benutzer der Datenbank.
Der Härtungsleitfaden weist darauf hin, dass der laufende Betrieb nur SELECT, INSERT, UPDATE und DELETE braucht. Er rät nicht dazu, DROP, ALTER und GRANT zu entziehen, weil Plugins und größere Updates das Schema unter Umständen ändern müssen. Wenn Sie diese Rechte trotzdem entfernen, halten Sie getestete Backups bereit.
10. Dateiberechtigungen setzen
Der Leitfaden empfiehlt als Ausgangspunkt 755 für Verzeichnisse und 644 für Dateien. Kerndateien, wp-admin und wp-includes sollten nur für Ihr Benutzerkonto beschreibbar sein, nicht für den Webserver. wp-content ist die Ausnahme: Dort muss der Webserver für Uploads schreiben können. Für wp-config.php schlägt der Leitfaden 400 oder 440 vor.
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.phpPassen Sie Pfade und Eigentümer an Ihre Hosting-Umgebung an, bevor Sie diese Befehle ausführen.
11. Security-Header senden
Header wie Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options und Referrer-Policy sorgen für zusätzlichen Schutz im Browser. Setzen Sie sie nach Möglichkeit auf dem Webserver oder im CDN statt über ein Plugin. Beginnen Sie mit einer Content Security Policy im Report-only-Modus, denn Themes und Page-Builder setzen oft auf Inline-Skripte.
12. Eine WAF vorschalten
Die WordPress-Dokumentation beschreibt drei Ebenen: Sicherheits-Plugins, die Anfragen innerhalb von WordPress filtern, eine Firewall auf Serverebene wie ModSecurity und Reverse-Proxy-Dienste, die den Datenverkehr filtern, bevor er Ihren Server erreicht. Je weiter außen gefiltert wird, desto weniger Last erreicht PHP. Eine WAF ersetzt keine Updates. Sie verschafft Ihnen Zeit zwischen der Veröffentlichung einer Schwachstelle und Ihrem Patch.
Die Kurzfassung
| Bereich | Minimum |
|---|---|
| Updates | Automatische Minor-Updates des Kerns aktiv, Plugins wöchentlich geprüft |
| Plugins | Keine geschlossenen, verwaisten oder ungenutzten Plugins installiert |
| Konten | Namentliche Konten, wenige Administratoren, 2FA für alle |
| Anmeldung | Begrenzung auf Server oder Netzwerkrand, XML-RPC gesperrt, wenn ungenutzt |
| Codeänderungen | DISALLOW_FILE_EDIT gesetzt |
| Backups | Außerhalb des Servers, außerhalb des Web-Roots, Wiederherstellung getestet |
| Integrität | Prüfsummen verifiziert, kein PHP in Uploads |
| Datenbank | Ein Benutzer pro Website, Rechte nur auf die eigene Datenbank |
| Browser | HSTS und eine getestete CSP |
| Perimeter | WAF oder Reverse Proxy vorgeschaltet |
Wo Sie anfangen
Beginnen Sie mit den ersten vier Punkten. Sie kosten wenig Zeit und erfordern keine Änderungen am Hosting. Prüfen Sie dann Ihre aktuellen Header mit unserem Security-Header-Scanner.
Wenn Sie das prüfen lassen möchten: SecAudit scannt WordPress auf Malware und Web-Shells, prüft die Dateiintegrität anhand offizieller Prüfsummen und gleicht installierte Plugins mit bekannten Schwachstellen ab.
