Zum Hauptinhalt springen

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

RolleKann u. a.

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_role auf „administrator“; diese Option gehört ins Monitoring.
  • Regelmässige Audits: wp user list --role=administrator und 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

Quellen und Dokumentation