Guide

WordPress Sicherheit: die Checkliste – was du einstellst, und wie du merkst, dass es so bleibt

WordPress Sicherheit bedeutet meist eine Liste von Dingen, die du einmal einschaltest: Zwei-Faktor-Login, Updates, HTTPS, Backups, eine Firewall. Das Problem: Jeder einzelne Punkt kann sich leise wieder auflösen. Ein neuer Administrator taucht auf, ein Hosterwechsel aktiviert wieder eine alte TLS-Version, ein Backup-Plugin läuft nicht mehr. Dieser Leitfaden geht die Checkliste Punkt für Punkt durch, basierend auf WordPress' eigener Dokumentation, und sagt zu jedem, wie du ihn einstellst und wie du merkst, wenn er nicht mehr stimmt.

Warum eine einmalige Checkliste nicht reicht

Das meiste Risiko steckt in Plugins, und es verändert sich schnell. Patchstack zählte 2025 11.334 neue Schwachstellen im WordPress-Ökosystem, 42 % mehr als 2024: 91 % betrafen Plugins, 9 % Themes und nur 6 WordPress selbst. 46 % hatten zum Zeitpunkt der Veröffentlichung noch keinen Fix vom Entwickler, und bei den am häufigsten angegriffenen Schwachstellen lag die mittlere Zeit bis zur ersten massenhaften Ausnutzung bei 5 Stunden.

Eine Website, die im Januar sicher war, kann also im März verwundbar sein, ohne dass jemand etwas angefasst hat. Die folgenden Maßnahmen empfehlen WordPress' eigene Seiten zum Hardening und zu Brute-Force-Angriffen. Zu jeder sagen wir, ob sie sich dauerhaft überwachen lässt und welcher Relvato-Monitor das übernimmt. Wo nichts überwacht, sagen wir das ebenfalls.

1. Konten und Login

Verwende für jedes Konto, das sich anmelden kann, ein einzigartiges, langes Passwort, und aktiviere Zwei-Faktor-Authentifizierung für jeden Administrator. WordPress selbst bringt keine Zwei-Faktor-Authentifizierung mit: Die Brute-Force-Seite rät, sie für alle Administratoren und privilegierten Nutzer mit einem vertrauenswürdigen Plugin einzuschalten. Das Two-Factor-Plugin, von WordPress-Mitwirkenden gebaut und auf WordPress.org gelistet, ist eine gute Standardwahl.

Halte die Zahl der Administratoren klein. Gib jeder Person die niedrigste Rolle, die für ihre Aufgabe reicht, entferne ungenutzte Konten, und achte auf Administratoren, die du nicht wiedererkennst; unser Leitfaden zu WordPress Benutzerrollen erklärt, warum jeder zusätzliche Administrator ein weiterer Weg hinein ist. Auch Anwendungspasswörter und WooCommerce-API-Keys lohnen einen Blick: Sie sind für Programme gedacht, nicht für Menschen, und melden sich an der REST-API und bei XML-RPC an – ohne Login-Formular und ohne Zwei-Faktor.

Begrenze Login-Versuche. WordPress' Brute-Force-Seite empfiehlt, das am Rand zu tun, also in der Firewall deines Hosters oder in einem CDN, und sagt, dass ein Sicherheits-Plugin Versuche drosseln kann, wenn das am Rand nicht passiert; ein CAPTCHA wie Turnstile am Login-Formular hilft zusätzlich.

Was sich überwachen lässt: Der Admin-Liste-Monitor meldet einen neuen Administrator, einen vor dem Benutzer-Bildschirm versteckten Administrator, ein neues Anwendungspasswort oder einen neuen API-Key, mehr als drei Administratoren, Administratoren, die sich seit 90 Tagen nicht angemeldet haben, und Administratoren ohne eingerichtetes Zwei-Faktor im Zwei-Faktor-Plugin der Website. Sobald du das Aktivitätsprotokoll im Plugin einschaltest, meldet es außerdem Redakteure und Autoren, bei denen sich seit 90 Tagen niemand angemeldet hat, und Aktivitätsprotokoll & Admin-Anmeldungen meldet Spitzen bei fehlgeschlagenen Anmeldungen und Administratoren, die sich aus einem neuen Netzwerk anmelden. Der Exposure-Scan warnt, wenn die Login-Seite offen liegt, ohne dass sichtbar etwas sie schützt: kein Login-Schutz-, CAPTCHA- oder Zwei-Faktor-Plugin und keine Firewall davor. Zwei-Faktor, das in einem Plugin eingerichtet ist, das Relvato nicht lesen kann, etwa Shield, zählt in keine Richtung.

2. Updates, Plugins und Themes

Halte WordPress, Plugins und Themes aktuell; WordPress' Hardening-Seite sagt klar, dass ältere Versionen nicht mehr mit Sicherheitsupdates versorgt werden. Installiere Sicherheitsreleases sofort nach Erscheinen, aktualisiere ein Plugin nach dem anderen, und prüfe danach die relevanten Seiten. Unser Leitfaden WordPress-Wartung hat dafür einen Zeitplan.

Weniger Plugins bedeuten weniger Schwachstellen. Lösche Plugins und Themes, die du nicht nutzt, statt sie nur zu deaktivieren, denn inaktiver Code bleibt erreichbar. Ersetze Plugins, die WordPress.org geschlossen hat oder die seit Jahren nicht aktualisiert wurden, und kaufe Premium-Plugins direkt beim Entwickler, nie bei einer Seite, die sie weiterverbreitet.

Was sich überwachen lässt: Der Schwachstellen-Monitor meldet Plugins, Themes und WordPress-Versionen mit bekannten Schwachstellen, Plugins mit wartendem Update (und nennt es, wenn das Changelog einen Sicherheitsfix erwähnt), auf WordPress.org geschlossene oder seit zwei Jahren aufgegebene Plugins, inaktive Plugins und Themes, und aktive Plugins, die nicht von WordPress.org stammen, damit du bestätigen kannst, woher jedes kommt. In bezahlten Plänen wird die Website erneut gescannt, sobald ein neues Advisory ein Plugin nennt, das auf deiner Seite läuft.

3. HTTPS, TLS und Security-Header

Liefere die gesamte Website über HTTPS aus und leite jede http-Adresse darauf weiter. Akzeptiere nur TLS 1.2 und 1.3: RFC 8996 hat TLS 1.0 und 1.1 2021 für veraltet erklärt und sagt, sie dürfen nicht mehr verwendet werden. Diese Einstellungen liegen bei deinem Hoster oder CDN, nicht in WordPress – deshalb können sie sich ändern, wenn du den Hoster wechselst oder der Hoster seine Standardwerte anpasst.

Setze einen HSTS-Header, damit Browser nie auf http zurückfallen. Starte mit einem kurzen max-age und erhöhe ihn, sobald du sicher bist, dass jede Subdomain über HTTPS funktioniert; die HSTS-Preload-Liste verlangt mindestens ein Jahr (31536000 Sekunden), aber trage preload nur ein, wenn du es ernst meinst. Unser Leitfaden zu HTTP Security-Headern behandelt HSTS und die anderen Header, die sich lohnen.

Was sich überwachen lässt: Der SSL-Zertifikat-Monitor meldet ein abgelaufenes, nicht vertrauenswürdiges oder bald ablaufendes Zertifikat sowie einen Server, der noch TLS 1.0 oder 1.1 akzeptiert. Weiterleitungen & kanonischer Host meldet eine http-Adresse, die die Seite ausliefert statt weiterzuleiten. Mixed Content findet http-Ressourcen auf https-Seiten, und der Exposure-Scan meldet fehlende Security-Header und einen HSTS max-age unter 180 Tagen.

4. Abschalten, was du nicht nutzt

Deaktiviere XML-RPC, wenn nichts es nutzt; genau das sagt WordPress' Brute-Force-Seite. Jetpack, die WordPress-App und manche Integrationen brauchen es noch, also prüfe das vorher.

Schalte den Plugin- und Theme-Datei-Editor ab mit define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php. WordPress' Hardening-Seite merkt an, dass das einen Angreifer nicht am Hochladen von Dateien hindert, aber es bedeutet, dass eine gestohlene Administrator-Sitzung kein laufendes PHP mehr über das Dashboard bearbeiten kann.

Verhindere, dass die Website ihre Nutzer und Versionen verrät: der Users-Endpoint der REST-API, Autoren-Archive unter /?author=1, der Generator-Tag und eine öffentliche readme.html helfen einem Angreifer alle dabei, Benutzernamen und verwundbare Versionen zu finden. Und halte Debug-Ausgaben vor Besuchern verborgen: PHP-Fehler auf einer Seite verraten Dateipfade und Abfragen.

Was sich überwachen lässt: Der Exposure-Scan meldet eingeschaltetes XML-RPC, den aktivierten Datei-Editor, Nutzer-Enumeration über die REST-API oder Autoren-Archive, Versions-Leaks und Debug-Ausgaben, die Besucher sehen können. Für die meisten davon gibt es einen Ein-Klick-Fix mit Undo, beschrieben in WordPress-Sicherheitshärtung. WP_DEBUG, das in ein privates Log schreibt, wird nicht gemeldet – ein debug.log, das jeder herunterladen kann, dagegen schon.

5. Dateien, Berechtigungen und was im Web-Root nichts zu suchen hat

WordPress' Seite zu Datei-Berechtigungen gibt die Zahlen vor: Dateien 644 oder 640, Ordner 755 oder 750, und wp-config.php 440 oder 400, damit andere Nutzer auf dem Server sie nicht lesen können. Kein Ordner sollte je 777 sein, auch nicht uploads.

Räume auf, was im Web-Root nichts zu suchen hat: Datenbank-Dumps, Zip-Backups, Kopien von wp-config.php wie wp-config.php.bak, .env-Dateien und .git-Ordner. Jedes davon kann die ganze Website an jeden ausliefern, der die Adresse errät.

Was sich überwachen lässt: Der Exposure-Scan sucht nach offen liegenden .env-Dateien, .git-Ordnern, wp-config.php-Kopien, SQL-Dumps, Backup-Archiven und einem öffentlichen debug.log. Mit angebundenem Relvato-Plugin meldet die Website diese Dateien von innen, zusammen mit PHP-Dateien in uploads und Beispiel-Sicherheitsschlüsseln. Außerdem liest er die Berechtigungen von wp-config.php und .htaccess: jede der beiden, die irgendjemand auf dem Server ändern kann, und eine wp-config.php, die andere Konten lesen können, wenn PHP unter ihrem eigenen Besitzer läuft. Die Berechtigungen anderer Dateien werden nicht überwacht. Der Dateiintegritäts-Monitor vergleicht WordPress' Dateien mit den offiziellen Checksummen und meldet unerwartete PHP-Dateien und versteckte Plugins, und Theme-Integrität meldet in uploads abgelegte Programme und bösartigen Code in wp-config.php oder .htaccess.

6. Backups, die du wiederhergestellt hast

Sichere Datenbank und Dateien: wöchentlich für eine kleine Website, täglich für eine stark genutzte, und immer vor einem Upgrade – so empfiehlt es WordPress' Backup-Seite. Bewahre Kopien an unterschiedlichen Orten auf, denn ein Backup, das auf demselben Server liegt, geht mit ihm unter, wenn er gehackt wird oder ausfällt.

Ein Backup zählt nur, wenn es sich wiederherstellen lässt. WordPress' Hardening-Seite verlangt Backups, die du getestet hast und die sich problemlos wiederherstellen lassen. Stelle alle paar Monate eines auf einer Staging-Website wieder her.

Was sich überwachen lässt: Der Backups-Monitor liest UpdraftPlus, BackWPup, Duplicator, WPvivid und andere Backup-Plugins aus. Er meldet ein letztes abgeschlossenes Backup, das älter als sieben Tage ist, fehlgeschlagene oder hängende Backups, keinen Zeitplan und Backups, die nur auf demselben Server liegen. Ob sich Restores testen lassen, prüft Relvato nicht: Das bleibt auf deiner eigenen Liste.

7. Firewall, Malware und die Zeichen, die ein Scanner übersieht

Stelle eine Web Application Firewall vor die Website, bei deinem Hoster oder CDN, oder als Plugin. Verlass dich nicht allein auf den Hoster: In Patchstacks Tests blockierten Hosting-Abwehrmaßnahmen nur 26 % der Angriffe. Unser Vergleich Wordfence vs. Sucuri behandelt die beiden bekanntesten Optionen.

Relvato meldet nicht, ob eine Firewall vor deiner Website steht. Es beobachtet, was durchkommt: Anzeichen eines Hacks sucht nach Spam-Seiten, Cloaking und Weiterleitungen auf andere Websites, so wie Besucher und Google sie sehen, und Drittanbieter-Skripte meldet ein Skript von einem neuen Ursprung auf deinen wichtigsten Seiten, einschließlich des Checkouts – genau so kommen Kartenskimmer hinein.

Kommt doch etwas durch, behandelt unser Leitfaden WordPress gehackt Checkliste, was zuerst zu tun ist, einschließlich der Stellen, die kein Scanner sieht. Nach einer Bereinigung überwacht der Quarantäne-Modus 48 Stunden lang stündlich die Dateien, Administratoren und Skripte der Website.

Was Monitoring braucht, und was es nicht kann

Die meisten Punkte von innen, etwa Administratoren, Plugins, Backups und Dateiintegrität, brauchen das angebundene Relvato-WordPress-Plugin, das zugleich beweist, dass dir die Website gehört. Die Punkte von außen, etwa Zertifikate, TLS, Weiterleitungen und Header, funktionieren bei jeder Website. Wie oft sie laufen, hängt vom Plan ab: höchstens wöchentlich bei Free, täglich bei Pro und stündlich bei Business, und bei Pro und höher nach jedem Plugin- oder Theme-Update.

Monitoring sagt dir, wenn ein Punkt nicht mehr stimmt. Es stellt die Punkte nicht für dich ein, und es ersetzt keine Firewall, kein Backup-Plugin und kein Zwei-Faktor-Login. Behandle diese Checkliste als zwei Listen: die Maßnahmen, die du einmal einstellst, und die, über die du am Tag ihrer Änderung Bescheid wissen willst.

WordPress Sicherheit: die Maßnahme, und was sie überwacht

MaßnahmeWie du sie einstellstÜberwacht von
Zwei-Faktor für AdministratorenEin Zwei-Faktor-Plugin, etwa Two FactorAdmin-Liste: Administratoren ohne eingerichtetes Zwei-Faktor; der Exposure-Scan warnt, wenn die Login-Seite ungeschützt ist
Wenige Administratoren, keiner vergessenNiedrigste Rolle pro Person; ungenutzte Konten entfernenAdmin-Liste: neue, versteckte oder inaktive Administratoren, inaktive Redakteure und Autoren, neue Anwendungspasswörter
Brute-Force-SchutzRate-Limiting bei Firewall oder CDN, ein CAPTCHA oder ein Login-Limit-PluginAktivitätsprotokoll & Admin-Anmeldungen: Spitzen bei fehlgeschlagenen Anmeldungen, neue Netzwerke
UpdatesSicherheitsreleases sofort, andere Updates wöchentlichSchwachstellen-Monitor: bekannte Schwachstellen, wartende Updates
Keine ungenutzten oder aufgegebenen PluginsInaktive Plugins und Themes löschen; geschlossene ersetzenSchwachstellen-Monitor: inaktive, geschlossene und aufgegebene Plugins, und Plugins, die nicht von WordPress.org stammen
HTTPS, TLS 1.2+, HSTSEinstellungen bei Hoster oder CDN; ein HSTS-HeaderSSL-Zertifikat, Weiterleitungen & kanonischer Host, Exposure-Scan
XML-RPC und Datei-Editor ausXML-RPC deaktivieren; DISALLOW_FILE_EDIT in wp-config.phpExposure-Scan, mit Ein-Klick-Fix
Keine Nutzer- oder Versions-LeaksNutzerliste und Autoren-Archive blockieren; Generator-Tag entfernenExposure-Scan
Datei-Berechtigungen644/755, wp-config.php 440 oder 400, nie 777Exposure-Scan: nur wp-config.php und .htaccess
Nichts Sensibles im Web-RootDumps, Archive, .env, .git und Config-Kopien entfernenExposure-Scan
Backups außerhalb des Servers, Restore getestetEin Backup-Plugin mit Remote-Speicher; alle paar Monate ein RestoreBackups-Monitor; Restores liegen bei dir
FirewallEine WAF bei Hoster, CDN oder als PluginNicht gemeldet; Anzeichen eines Hacks und Drittanbieter-Skripte beobachten, was durchkommt

Fragen und Antworten

Was sollte eine WordPress-Sicherheits-Checkliste enthalten?

Zwei-Faktor-Login für Administratoren, wenige Administrator-Konten, begrenzte Login-Versuche, zügige Updates, keine ungenutzten oder aufgegebenen Plugins, HTTPS mit TLS 1.2 oder neuer und HSTS, abgeschaltetes XML-RPC und Datei-Editor, korrekte Datei-Berechtigungen, nichts Sensibles im Web-Root, Backups außerhalb des Servers und getestet, und eine Firewall.

Hat WordPress Zwei-Faktor-Authentifizierung integriert?

Nein. WordPress Core bringt keine Zwei-Faktor-Authentifizierung mit, und die eigene Dokumentation empfiehlt dafür ein Plugin für alle Administratoren. Das Two-Factor-Plugin auf WordPress.org wird von WordPress-Mitwirkenden gebaut.

Sollte ich XML-RPC in WordPress deaktivieren?

Ja, wenn nichts es nutzt. WordPress' Brute-Force-Empfehlung sagt, es zu deaktivieren, wenn du es nicht brauchst. Jetpack, die WordPress-App und manche Integrationen sind noch darauf angewiesen, also prüfe das zuerst.

Macht ein geänderter Datenbank-Tabellenpräfix WordPress sicherer?

Nur ein wenig. WordPress' Hardening-Seite sagt, das könne manche SQL-Injection-Angriffe blockieren, zählt es aber zur Security through Obscurity, die sie als keine solide Hauptstrategie bezeichnet. Updates, Zwei-Faktor-Login und eine Firewall zählen weit mehr.

Brauche ich ein Sicherheits-Plugin?

Du brauchst, was ein Sicherheits-Plugin normalerweise liefert: Login-Schutz, Zwei-Faktor-Login und eine Firewall. Das kann auch von deinem Hoster oder einem CDN kommen. Ein Plugin läuft innerhalb von WordPress, verbraucht bei einem starken Angriff also die Ressourcen der Website selbst – deshalb bevorzugt WordPress Rate-Limiting am Rand.

Quellen

Weiterführende Artikel
Guide

Erfahre am selben Tag, wenn sich ein Punkt deiner Checkliste wieder auflöst.

Relvato überwacht Administratoren, Plugins, Zertifikate, Dateien und Backups und lässt die Monitore nach jedem Update erneut laufen.