WordPress-Sicherheit

Jede Website sollte sicher sein! Denn wer möchte schon gerne einen Einbrecher in seinem zu Hause begrüßen? Im digitalen Umfeld lauern zudem weitere Schwierigkeiten, denn die eigene Webseite kann als Spam-Maschinerie missbraucht werden. Daher beachte bitte die wichtigsten Punkte für ein sicheres WordPress.

Deine Sprungmarken Bitte Anzeigen

Zusammenfassung: WordPress sicher gestalten

WordPress selbst ist (ziemlich) sicher. Daher bedenke bitte folgende Hauptregeln:

regelmäßige Backups anlegen
kontinuierlich Plugins aktualisieren
so wenig Plugins wie möglich verwenden
lange Passwörter nutzen

Der Rest liegt an dir. Aber auch hier gibt es einfache und schnell erledigte Dinge:

Standard-WP-Pfade ändern (Datenbank/FTP)
wp-login und wp-admin mit Benutzernamen und Passwort schützen
Ungewöhnlichen Namen für deinen WP-Administrator verwenden
Beiträge nicht mit deinem Administrator veröffentlichen
Login-Namen und Anzeigenamen trennen
2-Faktor Authentifizierung nutzen
Speicherort deiner wp-config.php ändern
wp-config.php via .htaccess schützen

Direkte Anwendungsbeispiele, die ein großes Plus an Sicherheit bringen, allerdings in Ihrer Initialisierung aufwendiger sind:

CSP Security Header einstellen

Die lange Version zur Sicherheit …

Wenn ich schreibe „Der Rest liegt an dir“, hat das seine Vor- und Nachteile, was den Aufwand angeht und je nachdem wie tief du selbst damit umgehen möchtest. Ich versuche dir einen allgemeinen Überblick zum Theme Sicherheit und WordPress zu geben, damit du selbst den für dich benötigten Rahmen einschätzen und dich dann für deine „richtige Lösung“ entscheiden kannst. Ziel sollte ein halbwegs sicheres WordPress sein, damit du es erst gar nicht zu einem erfolgreichen Angriff kommen lässt.

Faktencheck: WordPress ist unsicher

Fangen wir an mit der einfachen, aber prägenden Aussage: „WordPress ist unsicher!“
Klingt erst einmal wichtig, wo doch so viel passiert dieser Tage. Wenn es wieder mal um gehackten Seiten geht, steckt oft ein WordPress dahinter. Natürlich ist es dann einfach zu sagen, dass es genau daran liegt. Nun solltest du wissen, dass ca. 44 % der Websites weltweit mit WordPress erstellt wurden¹, was die Wahrscheinlichkeit deutlich erhöht, auch einen Angriff zu erleiden. Leider werden oft die medienwirksamen Worte genutzt, um möglichst viele Leser zu generieren. Und so liest man schnell, dass WordPress Webseiten von einem Hack betroffen sind, sobald es jedoch ins Detail geht, liegt es manchmal garnicht am WordPress selbst. Schnell kann es eine andere Lücke gewesen sein², welche dann erst die WordPress Zugangsdaten freilegte und so wiederum der Zutritt zur Seite erfolgte. Mit einem unsicheren WordPress hat das jedoch wenig zu tun.

Betrachten wir für einen Augenblick mal nur WordPress selbst, ohne jegliche Erweiterungen in Form von Plugins und stets auf der aktuellsten Version gehalten, steht der Core von WordPress vernünftig da. Sobald Plugins, Theme-Anpassungen oder andere funktionale Erweiterungen eingebaut werden, kann es dazu kommen, dass man neue Funktionen einbindet, die wiederum neue Sicherheitslücken ermöglichen. Das bedeutet, dass man unter durch unsauberen oder veralteten Code auch Sicherheitslücken hinterlässt, worüber sich ein Angreifer Zugriff zu deiner Seite verschaffen kann. Und sobald bösartiger Code vom Angreifer ausgeführt werden kann oder sich der Angreifer einen Account für deine Seite erstellt hat, musst du mit allem weiteren rechnen. Denn nun bist du nicht mehr der alleinige Administrator deiner Seite.

Diese Einschätzung wird durch den „2024 Annual WordPress Security Report“ von Wordfence eindrücklich gestützt. Der Bericht hält fest, dass der WordPress-Core selbst weiterhin sehr sicher ist (mit nur 5 gemeldeten Schwachstellen im gesamten Jahr 2024). Die überwältigende Mehrheit der Risiken geht stattdessen von Erweiterungen aus: 96 % aller erfassten Schwachstellen entfielen auf Plugins, der verbleibende Rest auf Themes³.

Regelmäßige Updates sind ein wichtiger Punkt, denn viele alte Versionen mit bekannten Sicherheitslücken können entsprechend ausgenutzt werden, wenn sie nicht zeitnah aktalisiert wurden.

Vergiss bitte neben der Datensicherheit in Form von aktuellem Code bitte nicht die Nutzerseite. Denn es bringt dir nichts, wenn deine Seite einer Burg oder Fort Knox gleicht, du aber am Eingang ein Schild, mit den Zugangsdaten, hängen hast. Das bedeutet, achte darauf, dass Administrator oder Nutzer mit hoher System-Reichweite (z.B. WooCommerce Shop-Manager) über deine Seite auch sicher Passwörter nutzen. Nutze zudem keine Standard-Namen für Administrator Konten (admin, test-admin usw.), wenn du es vermeiden kannst. Und sichere dein eigenes Konto möglichst doppelt ab, beispielsweise über eine 2-Faktor-Authentifizierung. Im Idealfall verwendest du deine Administratoren nur um Veränderungen im Backend vorzunehmen. Veröffentliche keine Beiträge als Administrator. So bleibt die Identität geheim.

Es passieren täglich viele automatisierte Versuche auf allen möglichen Seiten mit den immer gleichen Zugangsdaten. Sobald deine Seite etwas bekannter ist, merkst du das am Spam. Dieser wird dir mittels Kommentarfunktion und Kontaktformular eingesendet.

Vermeide diese einfache, aber oft übersehene Stelle und halte deine aktiven Nutzerkonten sauber. Nur so kannst du sicher sein, dass der Angreifer nicht darüber kam. Um wirklich sicherzugehen, was die Bearbeiter auf deiner Seite so gemacht haben oder wann ein Plugin aktualisiert wurde, kann dir ein Logger sicher weiterhelfen, doch dazu später mehr. Schauen wir uns lieber mal an, was so passieren kann. Denn es ist egal, ob der Angreifer sich Admin-Zugriff zu deiner Seite ist oder im Code sein Unwesen treibt. Sollte deine liebevoll aufgebaute Seite einem Angriff zum Opfer gefallen sein, solltest du dafür aufmerksam sein. Schließlich bist du dafür verantwortlich.

WordPress Rest-API und interessante Endpunkte

Die REST-API (Representational State Transfer – Application Programming Interface) ist der Motor von WordPress für die moderne Webentwicklung. Sie wurde eingeführt (und 2015 vollständig in den Core integriert), um WordPress von einem reinen CMS zu einer „Headless“ oder „Decoupled“ Anwendungsplattform zu machen.

Stell dir die API als Kellner in einem Restaurant vor:

Das Backend (Küche): Deine WordPress-Datenbank (Beiträge, Seiten, Benutzer).
Das Frontend (Gast): Eine mobile App (iOS/Android), eine moderne JavaScript-Website (z.B. mit React oder Vue.js) oder ein anderes externes System.
Die REST-API (Kellner): Nimmt Anfragen vom „Gast“ entgegen (z.B. „Gib mir die 10 neuesten Beiträge“), holt die Daten aus der „Küche“ und liefert sie dem „Gast“ in einem sauberen, standardisierten Format (JSON) zurück.

Sie wird intensiv vom Block-Editor (Gutenberg) selbst, von vielen Plugins zur Datenverwaltung und eben für externe Anwendungen genutzt.

Warum existiert der /wp-json/wp/v2/users Endpunkt?

Wenn du deine Domain mit dem Anhängsel /wp-json/wp/v2/users aufrufst, erscheinen einige Meta-Informationen zu den Nutzern deiner Website. So siehst du beispielsweise, dass Maik der dritte Nutzer von deinwp.de ist und reen die ID-6 bekommen hat.

Dieser spezifische Endpunkt dient dazu, öffentliche Informationen über Benutzer abrufbar zu machen. Der Hauptgrund ist die Anzeige von Autoreninformationen.

Wenn ein Theme oder eine App einen Beitrag anzeigt, muss sie wissen, wer ihn geschrieben hat, um Dinge wie „Geschrieben von [Autorname]“, eine Autoren-Biografie oder einen Link zum Autorenarchiv anzuzeigen.

Wichtig: Standardmäßig zeigt dieser Endpunkt nicht alle Benutzer deiner Website an. Er listet nur Benutzer auf, die mindestens einen öffentlich sichtbaren Beitrag verfasst haben (also typischerweise „Autoren“, „Redakteure“ und „Administratoren“). Reine „Abonnenten“ (Subscriber) erscheinen dort normalerweise nicht. Dadurch stellt die Sichtbarkeit auch kein direktes Risiko dar.

Stellt dies ein Sicherheitsrisiko dar?

Der Endpunkt stellt ein potenzielles Risiko dar, ist aber nicht direkt gefährlich.

Das eigentliche Problem ist nicht der Endpunkt selbst, sondern die Offenlegung von gültigen Login-Namen. Wenn ein Angreifer (Bot) die API abfragt und eine Liste von Benutzernamen erhält (z.B. „admin“, „reen“, „maik“), hat er den ersten Teil eines Brute-Force-Angriffs bereits geschafft. Er muss „nur“ noch die Passwörter für diese bekannten Namen erraten.

Die Entwickler von WordPress argumentieren jedoch, dass Benutzernamen (Login-Namen) nicht als geheim angesehen werden sollten – Passwörter hingegen schon.

„Wie im Handbuch zum Melden von Sicherheitsschwachstellen angegeben, betrachten wir Benutzernamen (und damit die Existenz von Konten) nicht als privat. Ähnliches kann durch das einfache Durchsuchen der /author/{slug} Ansichten erreicht werden. Wir müssen Benutzerfreundlichkeit gegen Informationspreisgabe abwägen, und da Benutzernamen nicht als private Information gelten, gewinnt hier die Benutzerfreundlichkeit.“
Core Committer Sergey Biryukov⁴

Das Risiko entsteht fast ausschließlich dann, wenn Benutzer den identischen Login-Namen und Anzeigenamen verwenden (z.B. Login: admin, Anzeigename: admin). Die API gibt den „Slug“ (eine URL-freundliche Version des Anzeigenamens) aus. Wenn dieser mit dem Login-Namen übereinstimmt, ist der Login-Name öffentlich.

Selbst ohne die REST-API kann man Autorennamen oft erraten, indem man die Autoren-Archiv-URLs testet (z.B. domain.de/author/admin). Die API macht es für Bots nur einfacher und schneller.

Weitere Endpunkte sind beispielsweise /wp-json/wp/v2/media oder /wp/v2/themes .

Du könntest den Endpunkt für NIcht-Admins deaktivieren, solltest dir allerdings sicher sein, dass deine Plugins darauf nicht angewiesen sind.

# /wp-json/wp/v2/users Endpunkt deaktivieren

add_filter( 'rest_endpoints', function( $endpoints ) {
// Nur für nicht eingeloggte Benutzer
if ( ! is_user_logged_in() ) {
// Deaktiviert die /users/ Auflistung
if ( isset( $endpoints['/wp/v2/users'] ) ) {
unset( $endpoints['/wp/v2/users'] );
}
// Deaktiviert die /users/ Einzelansicht
if ( isset( $endpoints['/wp/v2/users/(?P[\d]+)'] ) ) {
unset( $endpoints['/wp/v2/users/(?P[\d]+)'] );
}
}
return $endpoints;
});

Dieser Code prüft, ob der Besucher eingeloggt ist. Wenn nicht, entfernt er die /users-Endpunkte (die Liste und die Einzelansicht) aus der API.

Gängige Sicherheits-Plugins bieten dir eine Einstellung, um die Benutzerauflistung per REST-API zu unterbinden (wird oft als „Disable user enumeration“ oder ähnlich bezeichnet).

Wurde mein WordPress gehackt?

Hier eine kleine Auswahl, woran du erkennst, ob deine WordPress Website evtl. gerade gehackt wurde:

Verunstaltung, ungewöhnliches Aussehen, sowie Verhalten und (Fehl-)Funktionen
ungewollte Links, Umleitungen oder gar injizierte Werbeanzeigen
ungewöhnlich hohes Mail-/Spam-Aufkommen (an dich oder auch an andere von deiner Seite)
dein Administrator Zugang funktioniert nicht mehr
deine Website ist offline, weil dein Hoster eingegriffen hat
deine Seite wurde von der Suche ausgeschlossen
neue Inhalte wurden erstellt, die nicht von dir stammen
Meldungen verschiedener Monitoring-Tools

Meine Bilder werden missbräuchlich genutzt

Es kann vorkommen, dass nicht die Seite als solche angegriffen wird, sondern der Inhalt gestohlen wird. Häufig passiert dies bei Bildern. Diese könntest du mit einem Wasserzeichen schützen, du kannst die Funktion der rechten Maustaste einschränken (kein Kontextmenü zum Abspeichern), das Hotlinking verbieten oder verschiedene Copyright-Hinweise in deine Inhalte einfügen.

3-2-1 Backup-Regel

3 – Mindestens drei Kopien anfertigen
2 – Mindestens zwei unterschiedliche Speichertechnologien verwenden
1 – Mindestens eine Kopie „außer Haus“ lagern
Quelle

Allgemeine Tipps für ein sicheres WordPress

Hier folgen standardisierte Tipps, um ein sicheres WordPress zu nutzen. Also Dinge, die jeder Administrator anwenden sollte!

nutze sicheres Hosting
lösche ungenutzte Plugins und Themes
update dein WordPress, sowie Plugins und Themes regelmäßig
arbeite bzw. veröffentliche nicht als Admin
vergib sichere Passwörter
nutze eine Zweiphasige Authentifizierung

Spezielle Sicherheitsempfehlungen

Mit den nachfolgenden Tipps legst du die Sicherheitsstufe für deine WordPress Seite weitere Prozentpunkte nach oben.

Verzeichnisschutz für den Login-Pfad

Diese einfache und zugleich brillante Lösung bietet einen effektiven Schutz, um automatisierte Angriffe noch vor dem Versuch selbst zu verhindern und entlastet bei starken Angriffswellen auch deinen Server. Wenn deine Seite unter starken Angriffen auf den Login-Bereich leidet, ist diese Variante zu empfehlen. Du kannst bei deinem Hoster oder über die .htaccess bestimmte Verzeichnisse mit einem zusätzlichen Passwortschutz versehen. Nutze dazu den /wp-admin/ Pfad deiner Seite. Bitte beachte jedoch, dass dadurch ggf. wenige Funktionen deiner Seite im Backend beeinträchtigt sein können. Und keine Bange sollte doch mal etwas nicht klappen. Schalte dann einfach den Verzeichnisschutz ab und teste es erneut, nur so weißt du, ob es auch wirklich daran liegt. Diese Lösung ist somit für größere Seiten mit vielen Backend-Funktionen möglicherweise nicht zu empfehlen und es bleibt im Einzelfall zu testen, ob alle Funktionen auch mit dem Verzeichnisschutz auskommen.

Theme-Editor deaktivieren

Hierzu muss in der Datei wp-config.php ein Eintrag geändert werden. Konkret von „true“ auf „false“ gestellt werden.

define('DISALLOW_FILE_EDIT', true);

So sieht das Admin-Menü mit Theme-Editor aus

Warum das Ganze? Nun, sollte wirklich mal ein nicht geladender Nutzer auf das Backend deiner Seite Zuriff haben, könnte er so direkt an die Bearbeitungsfunktion der PHP-Dateien deiner Seite gelangen. Mit dieser Sperre verhinderst du dies und es gibt weniger potenzielle Schwachstellen auf deiner Seite.