WordPress-Sicherheitscheckliste: Praktische Härtung für Website-Betreiber und Entwickler

Die meisten WordPress-Kompromittierungen beginnen nicht mit einer exotischen Zero-Day-Schwachstelle. Häufiger ist die Ursache alltäglich: ein aufgegebenes Plugin, ein wiederverwendetes Passwort, ein offengelegtes Hosting-Konto, übermäßige Berechtigungen oder ein Backup, das nie getestet wurde.

Diese WordPress-Sicherheitscheckliste konzentriert sich auf Prävention. Sie erläutert, wie Sie die Wahrscheinlichkeit einer Kompromittierung verringern, den Schaden durch ein gestohlenes Konto begrenzen und eine Wiederherstellung ermöglichen, falls Schutzmaßnahmen versagen. Wenn die Website bereits Besucher weiterleitet, verdächtige E-Mails versendet, unbekannte Administratorenkonten anzeigt oder Browser- bzw. Suchmaschinenwarnungen auslöst, behandeln Sie dies als aktiven Sicherheitsvorfall – nicht als routinemäßige Wartung. Sichern Sie Beweise und untersuchen Sie die Ursache, bevor Sie mit der Bereinigung beginnen.

Beginnen Sie mit einer genauen Bestandsaufnahme

Sie können eine WordPress-Website nicht absichern, wenn niemand einen verlässlichen Überblick darüber hat, was läuft, wer Zugriff hat und wo kritische Zugangsdaten hinterlegt sind. Eine Bestandsaufnahme deckt oft die tatsächlichen Risiken auf: eine vergessene Staging-Kopie, ein für eine einmalige Kampagne installiertes Plugin, ein altes Konto eines Auftragnehmers oder ein Domain-Registrar-Konto, das von einem einzigen Mitarbeiter kontrolliert wird.

Dokumentieren Sie Folgendes, bevor Sie Einstellungen ändern:

• WordPress-Core-Version, aktives Theme, Child-Theme und installierte Plugins;
• Zweck, Verantwortlichen und Aktualisierungsstatus jedes Plugins und Themes;
• Konten für WordPress-Administratoren, Hosting, Domain-Registrar, DNS, SFTP/SSH, Datenbank, Backups, E-Mail-Dienst und Zahlungsanbieter;
• Produktiv-, Staging- und Entwicklungsumgebungen sowie alte migrierte Kopien der Website;
• Backup-Speicherort, Häufigkeit, Aufbewahrungszeitraum und dokumentiertes Wiederherstellungsverfahren;
• Drittanbieterintegrationen, API-Schlüssel, Webhooks, Zahlungsdienste und Ziele von Formularen.

Löschen Sie inaktive Plugins und Themes, die nicht mehr benötigt werden. Inaktiver Code ist weiterhin Code auf dem Server: Er kann Schwachstellen enthalten, versehentlich reaktiviert werden oder die Untersuchung eines Sicherheitsvorfalls erschweren. Ein aktuelles Standard-WordPress-Theme als Notfall-Alternative zu behalten, ist sinnvoll; jahrelang alte kommerzielle Themes aufzubewahren, in der Regel nicht.

1. Etablieren Sie eine Update-Richtlinie, die keine Ausfälle verursacht

Updates gehören zu den wirksamsten Sicherheitsmaßnahmen für WordPress. Doch „alles sofort in der Produktionsumgebung aktualisieren“ ist keine Richtlinie. Bei einer Website mit individuellen Templates, WooCommerce-Erweiterungen, Caching oder externen Integrationen kann ein ungetestetes Update einen anderen Typ von Sicherheitsvorfall verursachen.

Ein praxisnaher Update-Prozess sieht so aus:

1. Bestätigen Sie, dass ein aktuelles Backup vollständig ist und wiederhergestellt werden kann.
2. Prüfen Sie den Umfang: WordPress-Core, Plugins, Themes, PHP und Serversoftware sind separate Ebenen.
3. Bei geschäftskritischen oder individualisierten Websites wenden Sie Änderungen zunächst in der Staging-Umgebung an.
4. Testen Sie die wichtigen Nutzerabläufe: Anmeldung, Formulare, Suche, Checkout, Zahlungs-Callbacks, Kundenkonten und individuelle Integrationen.
5. Stellen Sie in die Produktionsumgebung bereit und prüfen Sie Anwendungs- und Serverprotokolle auf neue Fehler.

WordPress-Minor-Releases sollten in der Regel zeitnah eingespielt werden, insbesondere wenn sie Sicherheitskorrekturen enthalten. Größere WordPress-Releases, Plugin-Updates und PHP-Upgrades verdienen bei komplexen Websites Kompatibilitätstests. Der genaue Rhythmus hängt von der Website ab, doch bekannte Updates monatelang unangetastet zu lassen, ist selten eine vertretbare Geschäftsentscheidung.

Prüfen Sie den PHP-Support im selben Prozess. WordPress läuft möglicherweise noch mit einer älteren PHP-Version, aber das bedeutet nicht, dass diese Version von den PHP-Maintainern oder Ihrem Hoster noch unterstützt wird. Planen Sie PHP-Upgrades als getestete Wartungsarbeiten, statt auf eine erzwungene Hosting-Änderung zu warten.

2. Reduzieren Sie Zugriffe, bevor Sie Sicherheitstools hinzufügen

Zugriffskontrolle ist wichtiger als das Verbergen der Login-URL oder die Installation mehrerer überlappender Sicherheits-Plugins. Sobald ein Angreifer über ein gültiges Administratorpasswort verfügt – oder Zugriff auf das für Passwort-Zurücksetzungen verwendete E-Mail-Konto hat –, bieten viele kosmetische Härtungsmaßnahmen nur wenig Schutz.

Verwenden Sie individuelle Konten und das Prinzip der geringsten Rechte

Jede Person sollte über ein eigenes WordPress-Konto verfügen. Gemeinsame Administratorkonten erschweren Offboarding, Nachvollziehbarkeit und die Untersuchung von Sicherheitsvorfällen unnötig. Weisen Sie die niedrigste Rolle zu, die eine Person für ihre Arbeit benötigt:

• Abonnent für Nutzer, die nur ein Konto benötigen;
• Mitarbeiter oder Autor für eingeschränkte Veröffentlichungsabläufe;
• Redakteur für Content-Management ohne Zugriff auf websiteweite Konfigurationen;
• Administrator nur für Personen, die Nutzer, Einstellungen, Plugins, Themes oder Code verwalten müssen.

Prüfen Sie Administratorkonten mindestens vierteljährlich und unmittelbar nach Änderungen bei Mitarbeitern, Agenturen oder Lieferanten. Ein unbekanntes Administratorkonto ist ein Signal für einen Sicherheitsvorfall, kein Punkt, der bis zur nächsten Prüfung warten sollte.

Fordern Sie einzigartige Passwörter und Multi-Faktor-Authentifizierung

Verwenden Sie lange, einzigartige Passwörter, die in einem vertrauenswürdigen Passwortmanager gespeichert sind. Verwenden Sie WordPress-Zugangsdaten nicht erneut für Hosting, Domain-Registrar, DNS, E-Mail oder andere Dienste. E-Mail verdient besondere Aufmerksamkeit, da die Kontrolle über ein Postfach für Passwort-Zurücksetzungen zur Kontrolle über die Website werden kann.

Aktivieren Sie Multi-Faktor-Authentifizierung für WordPress-Administratoren sowie für Hosting-, Domain-, DNS- und E-Mail-Konten, wo immer der Anbieter sie unterstützt. Prüfen Sie Wiederherstellungscodes, Wiederherstellungs-E-Mail-Adressen und registrierte Geräte im Rahmen des Offboardings. Eine Multi-Faktor-Authentifizierung, die an das Telefon eines ehemaligen Mitarbeiters oder an ein unbeaufsichtigtes Postfach gebunden ist, ist keine vollständige Schutzmaßnahme.

Schützen Sie Server- und Bereitstellungszugriffe

Deaktivieren Sie Konten, die nicht mehr benötigt werden. Bevorzugen Sie SSH-Schlüssel gegenüber passwortbasiertem SSH-Zugriff. Verwenden Sie getrennte Konten, wenn die Hosting-Plattform dies zulässt, und gewähren Sie nicht standardmäßig jedem Entwickler uneingeschränkten Zugriff auf die Produktionsumgebung. Datenbank-Zugangsdaten, Bereitstellungsgeheimnisse und API-Schlüssel sollten nicht in öffentlichen Repositories hinterlegt oder per gewöhnlicher E-Mail versandt werden.

3. Härten Sie WordPress-Konfiguration und Dateiberechtigungen

Härtung macht gängige Angriffswege weniger nützlich. Die Umsetzung hängt vom Hoster und Bereitstellungsmodell ab. Testen Sie Konfigurationsänderungen daher in der Staging-Umgebung und behalten Sie eine Möglichkeit zum Rollback bei.

Deaktivieren Sie den Datei-Editor im Dashboard in der Produktionsumgebung

Standardmäßig können WordPress-Administratoren Theme- und Plugin-Dateien über das Dashboard bearbeiten. Auf einer Produktionswebsite ist dieser Komfort eine Schwachstelle: Ein kompromittiertes Administratorkonto kann genutzt werden, um PHP-Code direkt zu verändern.

Fügen Sie diese Zeile in wp-config.php oberhalb der Zeile ein, die „That’s all, stop editing“ enthält:

define( 'DISALLOW_FILE_EDIT', true );

Dadurch werden die Datei-Editoren für Themes und Plugins im WordPress-Dashboard deaktiviert. Normale Updates werden dadurch nicht verhindert und die Serversicherheit wird nicht ersetzt. Nehmen Sie legitime Codeänderungen über einen kontrollierten Bereitstellungsprozess, SFTP oder SSH vor.

Nutzen Sie Berechtigungen zur Durchsetzung von Zuständigkeiten, nicht zur Umgehung von Fehlern

Schützen Sie wp-config.php mit Eigentümerschaft und Berechtigungen, die für Ihre Serverkonfiguration geeignet sind. Wenn der Hoster dies unterstützt, bewahren Sie sensible Konfiguration außerhalb des öffentlichen Document Root auf. Kopieren Sie Berechtigungswerte nicht blind aus einem Tutorial: Apache, PHP-FPM, Container und verwaltete WordPress-Plattformen können unterschiedliche Anforderungen haben.

Das Ziel ist einfach: WordPress und der vorgesehene Bereitstellungsprozess müssen die benötigten Dateien lesen oder ändern können, während nicht beteiligte Nutzer und Prozesse dies nicht können. Machen Sie Dateien oder Verzeichnisse nicht weltweit beschreibbar, nur um einen Update-Fehler zu lösen. Das verdeckt meist ein Bereitstellungs- oder Eigentümerschaftsproblem und vergrößert zugleich die Angriffsfläche.

Kontrollieren Sie, wer ausführbaren Code einführen darf

Für verwaltete Produktionswebsites sollten Sie einen Ablauf erwägen, bei dem die Installation von Plugins und Themes nur über einen freigegebenen Release-Prozess erfolgt. Dies ist nicht für jedes Redaktionsteam geeignet, aber wertvoll, wenn Entwickler Bereitstellungen verwalten und Content-Nutzer keinen neuen ausführbaren Code einführen können sollten.

Die Betriebsregel ist wichtiger als eine einzelne Einstellung: Legen Sie fest, wer in der Produktionsumgebung Code hinzufügen, aktualisieren und entfernen darf, und machen Sie diese Verantwortung ausdrücklich.

4. Schützen Sie Login- und Anwendungseinstiegspunkte

Automatisierte Login-Versuche sind auf öffentlichen WordPress-Websites alltäglich. Die sinnvolle Reaktion sind gestaffelte Schutzmaßnahmen, keine Sicherheitstheater.

• Fordern Sie Multi-Faktor-Authentifizierung für privilegierte Konten.
• Setzen Sie Ratenbegrenzung oder Kontrollen für Login-Versuche beim Hoster, CDN, einer Web Application Firewall oder auf einer geeigneten WordPress-Sicherheitsebene ein.
• Nutzen Sie ein CDN oder eine Web Application Firewall, wenn Traffic und Gefährdungslage der Website dies rechtfertigen, insbesondere bei wiederholten automatisierten Angriffen.
• Entfernen Sie ungenutzte Konten und vermeiden Sie vorhersehbare Administrator-Benutzernamen.
• Prüfen Sie XML-RPC anhand tatsächlicher Abhängigkeiten. Wenn keine benötigte mobile App, kein Veröffentlichungsablauf und keine Integration darauf angewiesen ist, kann eine Einschränkung unnötige Angriffsfläche reduzieren.

Das Ändern der Login-URL kann minderwertiges automatisiertes Rauschen verringern, ist aber keine primäre Sicherheitsgrenze. Es sollte niemals Multi-Faktor-Authentifizierung, Passwort-Hygiene, Rollenkontrolle und Ratenbegrenzung ersetzen.

5. Behandeln Sie Backups als Wiederherstellungsmaßnahme

Ein Backup ist nur nützlich, wenn es vollständig ist, von der kompromittierten Umgebung getrennt aufbewahrt wird und wiederhergestellt werden kann. Ein reines Datenbank-Backup kann Uploads und individuellen Code auslassen. Ein Backup, das nur im selben Hosting-Konto gespeichert ist, kann bei einer Kompromittierung dieses Kontos nicht verfügbar sein. Ein Backup, das nie wiederhergestellt wurde, ist eine Annahme, kein Wiederherstellungsplan.

Bewahren Sie sowohl Datenbank- als auch Datei-Backups auf, speichern Sie mindestens eine Kopie getrennt vom Produktions-Hosting-Konto und legen Sie die Aufbewahrung anhand der Geschäftsanforderungen fest. Eine E-Commerce-Website, die täglich Bestellungen verarbeitet, hat eine ganz andere Toleranz für Datenverlust als eine Unternehmenswebsite, die einmal monatlich aktualisiert wird.

Testen Sie die Wiederherstellung in einer nicht öffentlichen Umgebung. Bestätigen Sie, dass die wiederhergestellte Website lädt, Medien vorhanden sind, die erwarteten Daten existieren und kritische Funktionen wie Formulare oder Checkout funktionieren. Für Backup-Speicher gilt dieselbe Zugriffsdisziplin wie für die Produktionsumgebung: namentlich zugewiesene Nutzer, einzigartige Zugangsdaten und Multi-Faktor-Authentifizierung, sofern verfügbar.

Definieren Sie für größere Websites zwei Ziele:

• Recovery Point Objective (RPO): der maximal akzeptable Datenverlust. Ein RPO von 24 Stunden bedeutet, dass das Unternehmen den Verlust von Änderungen eines Tages akzeptieren kann.
• Recovery Time Objective (RTO): die maximal akzeptable Zeit für die Wiederherstellung des Dienstes.

Dies sind Geschäftsentscheidungen, keine technischen Bezeichnungen. Sie bestimmen Backup-Häufigkeit, Aufbewahrung, Hosting-Architektur und den erforderlichen Umfang der Wiederherstellungsvorbereitung.

6. Überwachen Sie bedeutende Änderungen, nicht nur Malware

Malware-Scans sind nützlich, aber ein sauberer Scan ist kein Beweis dafür, dass eine Website sicher ist. Die Erkennung hängt davon ab, was der Scanner erkennt, was er prüfen kann und wie sich die Kompromittierung verhält. Neue Administratorkonten, geänderte DNS-Einträge, unerwartete geplante Aufgaben, veränderte Dateien und ungewöhnliche ausgehende E-Mails können ebenso wichtige Signale sein.

Richten Sie eine Überwachungsroutine ein, die Folgendes umfasst:

• Muster fehlgeschlagener Logins und erfolgreiche Administrator-Logins;
• neue, gelöschte oder in ihren Berechtigungen geänderte WordPress-Nutzer;
• Änderungen am Core, an Plugins und Themes;
• unerwartete Änderungen an kritischen Dateien;
• Verfügbarkeit, Ablauf von TLS-Zertifikaten sowie Domain- oder DNS-Änderungen;
• Webserver- und PHP-Fehlerprotokolle, insbesondere nach Releases;
• ausgehendes E-Mail-Volumen und Formulareinsendungen, die auf Missbrauch hindeuten.

Wählen Sie Tools anhand der Umgebung aus, statt mehrere Plugins zu installieren, die alle Dateien scannen, Firewalls ausführen und Warnungen versenden. Ihr Hoster, CDN, Monitoring-Anbieter und vorhandene WordPress-Tools decken möglicherweise bereits Teile des Stacks ab. Doppelte Schutzmaßnahmen können Ressourcen verbrauchen, widersprüchliche Einstellungen erzeugen und dazu führen, dass niemand eindeutig für die Reaktion auf Warnungen verantwortlich ist.

7. Beziehen Sie individuellen Code und Integrationen in die Sicherheitsprüfung ein

WordPress-Sicherheit ist nicht auf das Dashboard beschränkt. Ein individueller REST-Endpunkt, Formular-Handler, Webhook, eine Zahlungsintegration oder ein maßgeschneidertes Plugin kann mehr Risiko einführen als die Standard-WordPress-Installation.

Prüfen Sie individuelle Funktionen nach wesentlichen Änderungen und bevor Sie sensible Systeme anbinden. Achten Sie besonders auf Autorisierungsprüfungen, Eingabevalidierung, Output-Escaping, Nonce-Verwendung für administrative Aktionen, Verarbeitung von Datei-Uploads, Speicherung von API-Schlüsseln und Fehlermeldungen, die interne Details offenlegen.

Für eine Website mit individuellen Plugins oder geschäftskritischen Integrationen liefert ein gezieltes WordPress-Code-Sicherheitsaudit Antworten, die eine Konfigurationscheckliste nicht liefern kann. Eine Checkliste reduziert routinemäßige operative Lücken; ein Code-Review untersucht Anwendungslogik, Berechtigungen und Vertrauensgrenzen.

Sicherheitsanforderungen sollten auch Teil der Abnahmekriterien für Relaunches und Integrationsarbeiten sein, nicht erst im Nachhinein berücksichtigt werden, wenn eine Funktion live ist. Weitere architektonische und wartungsbezogene Überlegungen finden Sie unter Planung von WordPress-Website-Optimierungen und Integrationen.

8. Definieren Sie die Schwelle für Sicherheitsvorfälle, bevor Sie sie brauchen

Keine Schutzmaßnahme garantiert, dass eine Website niemals kompromittiert wird. Der praktische Unterschied zwischen einem beherrschbaren und einem langwierigen Sicherheitsvorfall liegt oft darin, ob das Team Warnsignale früh erkennt und vermeidet, nützliche Beweise zu zerstören.

Eskalieren Sie unverzüglich, wenn Sie unerklärliche Administratorkonten, geänderte Zahlungsdaten, unbekannten Code in Plugin- oder Theme-Dateien, Spam-Weiterleitungen, Browser- oder Suchmaschinenwarnungen, ungewöhnliche ausgehende E-Mails oder verdächtige Aktivitäten in Hosting-Protokollen feststellen. Dokumentieren Sie die Beobachtungen, sichern Sie relevante Protokolle und Backups, beschränken Sie Zugriffe mit Bedacht und ziehen Sie den Hoster oder einen qualifizierten Incident-Response-Anbieter hinzu.

Gehen Sie nicht davon aus, dass das Löschen einer verdächtigen Datei oder das Aktualisieren von Plugins eine Kompromittierung beseitigt hat. Rotieren Sie nach der Wiederherstellung Zugangsdaten und Geheimnisse, identifizieren Sie den wahrscheinlichen Einstiegspunkt, prüfen Sie den möglichen Expositionszeitraum und schließen Sie die zugrunde liegende Lücke. Ein Backup wiederherzustellen, ohne die Ursache zu finden, kann dieselbe Schwachstelle einfach erneut herstellen.

WordPress-Sicherheitscheckliste: eine praktikable Wartungsroutine

Wöchentlich oder wenn Updates veröffentlicht werden

• Prüfen und installieren Sie getestete Updates für WordPress-Core, Plugins und Themes.
• Prüfen Sie den erfolgreichen Abschluss von Backups und untersuchen Sie Warnungen zu fehlgeschlagenen Backups.
• Prüfen Sie Sicherheits-, Verfügbarkeits- und Fehlerwarnungen, die Maßnahmen erfordern.

Monatlich

• Prüfen Sie Administratorkonten, installierte Plugins, Themes und Zugangsdaten für Integrationen.
• Testen Sie kritische Website-Abläufe, einschließlich Login, Formulare, Checkout und gegebenenfalls Kontobereiche.
• Prüfen Sie Protokolle und untersuchen Sie unerwartete Datei- oder Konfigurationsänderungen.

Vierteljährlich

• Testen Sie eine Wiederherstellung in einer sicheren, nicht öffentlichen Umgebung.
• Prüfen Sie den Zugriff auf WordPress, Hosting, DNS, Domain-Registrierung, E-Mail und Backup-Speicher.
• Bestätigen Sie, dass Multi-Faktor-Authentifizierungsmethoden und Wiederherstellungsdetails aktiven Mitarbeitern zugeordnet sind.
• Entfernen Sie alte Staging-Kopien, inaktive Dienste und Integrationen, die keinen geschäftlichen Zweck mehr haben.

Nach jeder größeren Änderung

• Testen Sie die Funktionalität und prüfen Sie die Protokolle.
• Verifizieren Sie, dass aktuelle Backups erfolgreich abgeschlossen wurden.
• Dokumentieren Sie neue Konten, API-Schlüssel, Berechtigungen und Drittanbieterabhängigkeiten.

FAQ

Reicht ein Sicherheits-Plugin aus, um WordPress abzusichern?

Nein. Ein Sicherheits-Plugin kann nützliches Monitoring, Login-Schutz und Warnungen bieten, aber es kann schwache Hosting-Zugriffe, wiederverwendete Passwörter, nicht unterstützte Serversoftware, unsicheren individuellen Code oder ungetestete Backups nicht ausgleichen. WordPress-Sicherheit erstreckt sich über die Anwendung, den Server, DNS, E-Mail, Backup-Speicher und die Personen, die Zugriff auf jede dieser Ebenen haben.

Sollte jedes WordPress-Plugin automatisch aktualisiert werden?

Automatische Updates können die Zeit verkürzen, in der bekannte Probleme offengelegt bleiben, insbesondere bei einfacheren Websites. Bei komplexen oder umsatzkritischen Websites sollten Updates mit Staging-Tests und einem Rollback-Plan kombiniert werden. Die richtige Wahl ist eine dokumentierte Richtlinie, die sich nach den Folgen von Ausfallzeiten und den Kapazitäten des Teams zur Überwachung von Änderungen richtet.

Macht das Verbergen der WordPress-Login-Seite eine Website sicher?

Nein. Es kann opportunistischen automatisierten Traffic reduzieren, aber Angreifer können WordPress-Installationen anhand anderer Signale identifizieren. Priorisieren Sie Multi-Faktor-Authentifizierung, starke einzigartige Passwörter, Rollen nach dem Prinzip der geringsten Rechte und Ratenbegrenzung.

Wie häufig sollte eine WordPress-Website gesichert werden?

Legen Sie die Backup-Häufigkeit entsprechend der Datenmenge fest, deren Verlust das Unternehmen verkraften kann. Eine Website, die Bestellungen, Registrierungen oder tägliche Inhaltsänderungen erhält, benötigt häufigere Wiederherstellungspunkte als eine statische Website. Beziehen Sie Dateien und Datenbank ein, bewahren Sie eine externe Kopie auf und testen Sie die Wiederherstellung regelmäßig.

Was sollte ich tun, wenn ich glaube, dass meine WordPress-Website gehackt wurde?

Behandeln Sie das Problem nicht als normale Update-Aufgabe. Sichern Sie Beweise, dokumentieren Sie die Symptome, beschränken Sie Zugriffe, wo angebracht, kontaktieren Sie bei Bedarf den Hoster und verwenden Sie einen strukturierten Bereinigungsprozess. Sobald die Website nachweislich sauber ist, nutzen Sie diese Checkliste, um die Bedingungen zu beheben, die die Kompromittierung ermöglicht haben.

Die praktische Priorität

Wenn Sie diesen Monat nur fünf Dinge tun, entfernen Sie unnötigen Code und unnötige Konten; installieren Sie überfällige Updates über einen getesteten Prozess; setzen Sie Multi-Faktor-Authentifizierung für privilegierte Zugriffe durch; verifizieren Sie eine externe Wiederherstellung; und prüfen Sie, wer Hosting, DNS, die Domain, E-Mail und Backups kontrolliert.

Diese Maßnahmen adressieren einen erheblichen Anteil vermeidbarer WordPress-Risiken, ohne einen Stapel von Plugins und falsche Sicherheit zu erzeugen. Wenn individuelle Funktionen, sensible Integrationen oder wesentliche geschäftliche Folgen beteiligt sind, ergänzen Sie den Wartungsplan um eine codefokussierte Sicherheitsprüfung.