WordPress-Sicherheit wird häufig als Werkzeugfrage behandelt und ist überwiegend eine Betriebsfrage. Die Angriffe, die tatsächlich stattfinden, sind automatisiert: Sie suchen nach bekannten Lücken in verbreiteten Erweiterungen und nach schwachen Zugängen. Wer beides schließt, hat den größten Teil erledigt.
Wo die Angriffsfläche liegt
| Quelle | Anteil an realen Vorfällen | Gegenmaßnahme |
|---|---|---|
| Veraltete Plugins | sehr hoch | Updates, weniger Plugins |
| Veraltete Themes | hoch | Updates, ungenutzte löschen |
| Schwache Zugänge | hoch | starke Passwörter, Zwei-Faktor |
| Veralteter Kern | mittel | automatische Nebenversionen |
| Veraltete PHP-Version | mittel | Hoster-Einstellung prüfen |
| Unsichere Dateirechte | niedrig | Standardwerte belassen |
| Gezielte Angriffe | sehr niedrig | betrifft kleine Seiten kaum |
Die Reihenfolge ist die Prioritätenliste. Die letzte Zeile ist der Grund, warum aufwendige Härtungsmaßnahmen bei einer kleinen Firmenwebsite selten den Aufwand rechtfertigen: Kleine Seiten werden nicht gezielt angegriffen, sondern maschinell mitgenommen.
Die Maßnahmen, die wirken
1. Updates, regelmäßig. Kern, Themes, Plugins. Nebenversionen des Kerns können automatisch laufen, Hauptversionen und Plugins nach kurzer Prüfung. Der Ablauf: Backup prüfen, Updates einspielen, Startseite und eine Unterseite aufrufen, Formular testen.
2. Starke, eindeutige Passwörter, verwaltet in einem Passwortmanager. Kein wiederverwendetes Passwort für den Administratorzugang.
3. Zwei-Faktor-Anmeldung für alle Konten mit Administratorrechten. Die wirksamste Einzelmaßnahme gegen automatisierte Anmeldeversuche.
4. Kein Benutzername admin. Und der Anzeigename sollte vom Anmeldenamen abweichen, weil der Anzeigename bei Beiträgen öffentlich ist.
5. Konten aufräumen. Jedes Konto, das nicht gebraucht wird, entfernen. Ehemalige Dienstleister und ausgeschiedene Mitarbeitende zuerst. Redakteursrechte statt Administratorrechte, wo es genügt.
6. Ungenutzte Themes und Plugins löschen, nicht nur deaktivieren. Ein deaktiviertes Plugin mit einer Lücke kann angreifbar bleiben, weil seine Dateien erreichbar sind.
7. Backups mit getesteter Wiederherstellung. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme. Einmal testen, dann weiß man es.
8. Aktuelle PHP-Version in der Hoster-Verwaltung wählen. Alte Versionen erhalten keine Sicherheitsupdates.
9. Anmeldebereich schützen, durch Begrenzung der Fehlversuche. Das reduziert die Last durch automatisierte Versuche erheblich.
10. Dateibearbeitung im Backend abschalten. Damit kann ein übernommenes Konto nicht direkt Code einfügen.
Was wenig oder nichts bringt
Die Anmeldeadresse umbenennen. Verhindert einen Teil der automatisierten Versuche, ist aber kein Schutz gegen jemanden, der die Seite ansieht. Wird oft als Hauptmaßnahme verkauft und ist eine Nebenmaßnahme.
Die WordPress-Versionsnummer verstecken. Angriffe prüfen nicht die Version, sie probieren die Lücke.
Ein umfassendes Sicherheitspaket ohne Updates. Das ist der häufigste Fehlschluss: Ein Plugin, das jede Woche einen Bericht schickt, ersetzt kein Update.
Aggressive Firewall-Regeln, die zu Fehlalarmen führen. Eine Firewall, die legitime Besucher blockiert, wird nach zwei Beschwerden abgeschaltet.
Betriebsablauf, monatlich
- Backup prüfen, dass es aktuell und vollständig ist
- Updates einspielen: Kern, Themes, Plugins
- Startseite, eine Unterseite und das Formular testen
- Benutzerkonten durchsehen
- Plugins auf verwaiste Produkte prüfen, also ohne Update seit über einem Jahr
- Search Console auf Sicherheitswarnungen prüfen
Schritt 3 ist der, der stille Fehler findet. Ein Formular, das nach einem Update keine Mails mehr versendet, meldet keinen Fehler. Es kommen einfach keine Anfragen.
Wenn es passiert ist
- Seite offline nehmen oder in Wartungsmodus setzen, um weitere Verbreitung zu stoppen
- Alle Passwörter ändern: WordPress, Datenbank, Hosting, FTP, E-Mail
- Unbekannte Administratorkonten entfernen
- Aus einem Backup vor dem Vorfall wiederherstellen, nicht das kompromittierte System reparieren
- Nach der Wiederherstellung sofort alle Updates einspielen, weil die Lücke im Backup noch vorhanden ist
- Search Console prüfen und, falls nötig, eine Überprüfung beantragen
- Ursache identifizieren, meist ein bestimmtes Plugin, und ersetzen
Punkt 5 ist entscheidend und wird häufig übersehen: Wer ein Backup zurückspielt und die Lücke nicht schließt, ist innerhalb von Tagen wieder betroffen.
Wer diesen Aufwand nicht tragen will, hat zwei legitime Alternativen: Managed WordPress mit eingekaufter Wartung, oder ein System ohne Laufzeitcode. Siehe WordPress-Alternativen.