Durchdachte Benutzerrollen gehören zu den günstigsten Sicherheitsmassnahmen in WordPress. Jeder zusätzliche Administrator ist ein zusätzlicher Weg zur vollständigen Übernahme der Website. Das Least-Privilege-Prinzip begrenzt den Schaden, wenn ein Account kompromittiert wird.
Die Standardrollen
| Kritisch, weil | ||
|---|---|---|
| Administrator | Plugins/Themes installieren, Benutzer anlegen, Code ausführen (indirekt) | Admin = Server-Code-Ausführung |
| Redakteur (Editor) | Alle Inhalte bearbeiten, unfiltered_html (Single Site) |
Kann JavaScript in Inhalte einfügen |
| Autor | Eigene Beiträge veröffentlichen, Medien hochladen | Uploads |
| Mitarbeiter | Eigene Beiträge schreiben, nicht veröffentlichen | gering |
| Abonnent | Profil verwalten | Ausgangspunkt vieler Privilege-Escalation-Lücken |
Wichtig: unfiltered_html
Administratoren und Redakteure dürfen auf Single Sites ungefiltertes HTML inkl. JavaScript speichern. Damit kann ein kompromittierter Redakteur-Account Skimmer oder Weiterleitungen einbauen. Wenn nicht benötigt:
define( 'DISALLOW_UNFILTERED_HTML', true );
Praxisregeln
- Persönliche Accounts statt geteilter Logins wie „admin“ oder „agentur“. Nur so sind Aktionen nachvollziehbar.
- Admin nur für Admin-Aufgaben: Für tägliche Redaktionsarbeit einen zweiten Account mit Redakteur-Rolle verwenden.
- Dienstleister-Zugänge befristen und nach Projektende löschen oder sperren.
- Registrierung deaktivieren, wenn nicht benötigt (Einstellungen → Allgemein), und die Standardrolle auf „Abonnent“ belassen. Manche Angriffe setzen über verwundbare Plugins
default_roleauf „administrator“; diese Option gehört ins Monitoring. - Regelmässige Audits:
wp user list --role=administratorund auf unbekannte Accounts prüfen. Angreifer legen gerne unauffällige Admins an. - Application Passwords (für REST-API-Zugriffe) pro Integration einzeln anlegen und nicht mehr genutzte widerrufen.
Eigene Rollen und Capabilities
Für spezielle Aufgaben (z. B. „Shop-Manager ohne Plugin-Rechte“, „SEO-Redaktion“) eigene Rollen anlegen, per Code in einem MU-Plugin statt per Plugin-UI:
add_action( 'init', function () {
if ( get_role( 'seo_editor' ) ) { return; }
add_role( 'seo_editor', 'SEO-Redaktion', [
'read' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'edit_published_posts' => true,
'edit_pages' => true,
'edit_others_pages' => true,
'edit_published_pages' => true,
] );
} );
Rollen werden in der Datenbank gespeichert (wp_user_roles in wp_options). Deshalb nur einmalig anlegen, nicht bei jedem Request neu schreiben.
In eigenem Code
Immer Capabilities prüfen, nicht Rollen: current_user_can( 'edit_post', $post_id ) statt Rollennamen zu vergleichen. Fehlende oder falsche Capability-Checks gehören zu den häufigsten Plugin-Schwachstellen.
Weiterführende Artikel
- Zwei-Faktor-Authentifizierung und Passkeys für WordPress
- Datei-Editor deaktivieren und Installationen einschränken
- REST-API und XML-RPC absichern oder einschränken