WordPress Editor vs. Administrator-Rolle: Ein vollständiger technischer Leitfaden

WordPress wird mit einem granularen rollenbasierten Zugriffskontrollsystem (RBAC) geliefert, das direkt in seinen Kern integriert ist. Von allen Standardrollen sind Administrator und Editor die zwei folgenreichsten — und die am häufigsten falsch zugewiesenen. Der Administrator verfügt über uneingeschränkte Kontrolle über jedes WordPress-Objekt, während der Editor über umfangreiche Inhaltsbefugnisse verfügt, aber keinen Zugriff auf Infrastruktur-Steuerelemente wie Themes, Plugins oder Website-Einstellungen hat.

Diese Unterscheidung falsch zu treffen ist keine geringfügige Unannehmlichkeit. Einem Content-Autor Administrator-Zugriff auf einer Produktionswebsite zu gewähren, ist eine direkte Angriffsfläche: Ein kompromittiertes Konto kann ein bösartiges Plugin installieren, die Datenbank exfiltrieren oder jeden anderen Benutzer aussperren. Dieser Leitfaden gibt Ihnen die technische Tiefe, um jedes Mal die richtige Entscheidung zu treffen.

Wie WordPress-Rollen und -Fähigkeiten tatsächlich funktionieren

Bevor die beiden Rollen verglichen werden, lohnt es sich, die zugrunde liegende Architektur zu verstehen. WordPress speichert Rollen nicht als feste Eigenschaft eines Benutzerkontos. Stattdessen speichert es ein serialisiertes Array von Fähigkeiten in der wp_usermeta-Tabelle unter dem Schlüssel wp_capabilities (wobei wp_ Ihr Tabellenpräfix ist). Jede Rolle ist einfach ein benanntes Bündel von Fähigkeiten, die in der WP_Roles-Klasse registriert sind.

Wenn ein Benutzer eine Aktion versucht — einen Beitrag veröffentlichen, ein Plugin löschen, das Profil eines anderen Benutzers bearbeiten — ruft WordPress current_user_can() auf, das die gespeicherten Fähigkeiten des Benutzers gegen das angeforderte Primitiv auflöst. Das bedeutet, dass Fähigkeiten additiv sind und, entscheidend, sie können pro Benutzer unabhängig von ihrer Rolle mithilfe von Plugins wie Members oder User Role Editor angepasst werden.

Die praktische Implikation: Wenn Sie einen Benutzer benötigen, der *fast* alles tun kann, was ein Editor tun kann, aber auch ein bestimmtes Plugin verwalten soll, müssen Sie ihn nicht zum Administrator hochstufen. Sie können eine einzelne zusätzliche Fähigkeit gewähren. Das Verstehen davon verhindert den häufigsten Fehler der Überprivilegierung im WordPress-Teammanagement.

Administrator-Rolle: Vollständige Aufschlüsselung der Fähigkeiten

Die Administrator-Rolle entspricht praktisch jeder primitiven Fähigkeit, die WordPress bereitstellt. Bei einer Einzelseiten-Installation umfasst dies unter anderem:

Kernfähigkeiten zur Website-Verwaltung:

manage_options — alle Einstellungen über wp-admin/options-general.php lesen und schreiben, einschließlich Website-URL, Admin-E-Mail, Permalink-Struktur und Zeitzone
install_plugins, activate_plugins, update_plugins, delete_plugins — vollständige Plugin-Lebenszyklussteuerung
install_themes, switch_themes, edit_themes, delete_themes — vollständige Theme-Lebenszyklussteuerung, einschließlich direkter Dateibearbeitung über den integrierten Theme-Editor (ein erheblicher Angriffsvektor)
edit_files — Zugriff auf den integrierten Code-Editor für Themes und Plugins (diese Fähigkeit ist deaktiviert, wenn DISALLOW_FILE_EDIT in wp-config.php auf true gesetzt ist)

Benutzerverwaltungsfähigkeiten:

create_users, edit_users, delete_users, promote_users, list_users — vollständige Autorität über jedes Benutzerkonto auf der Website, einschließlich der Möglichkeit, andere Administratoren herabzustufen oder zu löschen
remove_users — Benutzer aus einem Multisite-Netzwerk entfernen

Inhaltsfähigkeiten:

edit_others_posts, edit_published_posts, delete_others_posts, delete_published_posts, delete_private_posts

Erweiterte Fähigkeiten:

import — Inhalte über den WordPress-Importer importieren (kann verwendet werden, um beliebige Inhalte in großem Maßstab einzuschleusen)
export — den gesamten Inhalt der Website als XML-Datei exportieren, einschließlich aller Benutzerdaten
update_core — WordPress-Core-Updates auslösen
manage_categories, moderate_comments, unfiltered_html — rohen HTML einschließlich <script>-Tags ohne Bereinigung veröffentlichen

Die unfiltered_html-Fähigkeit verdient besondere Aufmerksamkeit. Bei einer Standard-Einzelseiten-Installation erhalten sowohl Administratoren als auch Editoren sie. Bei WordPress Multisite behalten nur Super-Admins sie. Dies ist eine bedeutende Sicherheitsgrenze: Ohne unfiltered_html entfernt der wp_kses_post()-Filter JavaScript und andere potenziell gefährliche Markierungen aus gespeicherten Inhalten.
Wann die Administrator-Rolle zugewiesen werden sollte

Die Person, der das Hosting-Konto gehört und die für die technische Integrität der Website verantwortlich ist
Ein geprüfter Entwickler oder DevOps-Ingenieur, der Theme-Entwicklung, Plugin-Konfiguration oder serverseitige Integrationsarbeit durchführt
Ein Migrationsspezialist während eines einmaligen Import-/Exportvorgangs (erwägen Sie, die Rolle danach zu widerrufen)

Kritischer Betriebshinweis: Weisen Sie einem gemeinsam genutzten oder generischen Konto niemals die Administrator-Rolle zu. Jeder Administrator muss eine namentlich genannte Person mit einem einzigartigen, starken Passwort und aktivierter Zwei-Faktor-Authentifizierung sein. Wenn Sie WordPress in einer VPS Hosting-Umgebung betreiben, kombinieren Sie die WordPress-Administrator-Hygiene mit der Benutzertrennung auf Betriebssystemebene — Ihr Webserver-Prozess sollte niemals als Root ausgeführt werden, und Ihr WordPress-Dateibesitz sollte sich von Ihrem Webserver-Benutzer unterscheiden.
Editor-Rolle: Aufschlüsselung der Fähigkeiten
Die Editor-Rolle ist speziell für Inhaltsoperationen konzipiert. Sie gewährt umfangreiche Autorität über Beiträge, Seiten, Medien, Kommentare und Taxonomie — schließt jedoch bewusst jede Fähigkeit auf Infrastrukturebene aus.
Inhaltsfähigkeiten, die ein Editor besitzt:

edit_posts, edit_others_posts, edit_published_posts, edit_private_posts

Was ein Editor ausdrücklich nicht tun kann:

• Auf wp-admin/options-general.php oder einen Einstellungsbildschirm zugreifen
• Plugins oder Themes installieren, aktivieren, deaktivieren oder löschen
• Andere Benutzerkonten als das eigene Profil anzeigen oder ändern
• WordPress-Core-Updates ausführen
• Auf die integrierten Theme- oder Plugin-Datei-Editoren zugreifen
• Permalink-Strukturen ändern, was alle vorhandenen URLs website-weit beschädigen würde
• Website-Daten exportieren oder importieren

Wann die Editor-Rolle zugewiesen werden sollte

• Ein leitender Redakteur oder Inhaltsdirektor, der den Redaktionskalender besitzt und Entwürfe von mehreren Mitwirkenden genehmigt
• Ein SEO-Spezialist, der Beiträge veröffentlichen, planen und optimieren muss, aber keinen Grund hat, Plugin-Einstellungen zu berühren
• Ein Social-Media- oder Marketing-Manager, der für die Aktivität des Blogs verantwortlich ist
• Ein Kunde, der seine eigenen Seiten aktualisieren muss, ohne das Risiko, die Website versehentlich zu beschädigen

Administrator vs. Editor: Direkter Vergleich

Sicherheitsimplikationen von Rollenzuweisungsfehlern

Das Problem des überprivilegierten Editors

Ein häufiges Muster in Agenturen: Einem Content-Autor wird Administrator-Zugriff gewährt, weil „es einfacher ist.” Dies schafft mehrere konkrete Risiken:

1. Plugin-Installation als Code-Ausführungsvektor. Jeder Administrator kann ein Plugin installieren. Ein Plugin ist PHP-Code, der auf Ihrem Server ausgeführt wird. Ein kompromittiertes Administrator-Konto entspricht der Ausführung von Remote-Code.
2. Credential-Harvesting über Export. Das WordPress-Export-Tool erstellt eine XML-Datei mit allen Beitragsinhalten, Kommentaren und Autoren-Metadaten. Ein Administrator kann dies unbemerkt auslösen.
3. Persistenz der Privilegieneskalation. Ein Angreifer, der Administrator-Zugriff erhält, kann ein neues Administrator-Konto erstellen und dann die Beweise löschen — den legitimen Eigentümer aussperrend.
4. unfiltered_html-Missbrauch. Selbst ohne Plugin-Zugriff kann ein Administrator <script>-Tags direkt in Beitragsinhalte einschleusen, was gespeicherte XSS-Angriffe gegen Website-Besucher ermöglicht.

Härtung der Administrator-Rolle

Über die Rollenzuweisung hinaus wenden Sie diese WordPress-Steuerelemente auf jeder Produktionswebsite an:

Fügen Sie Folgendes zu wp-config.php hinzu, um den integrierten Datei-Editor zu deaktivieren:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Also blocks plugin/theme installation

Beschränken Sie den WordPress-Admin-Bereich nach IP auf Serverebene. Für Nginx:

location /wp-admin/ {
    allow 203.0.113.0/24;
    deny all;
}

Für Apache fügen Sie zu .htaccess hinzu:

<Files "wp-login.php">
    Require ip 203.0.113.0/24
</Files>

Erzwingen Sie starke Passwörter und Zwei-Faktor-Authentifizierung mit einem Plugin wie WP 2FA oder Wordfence Login Security. Wenn Ihre Website auf einem Dedicated Server läuft, erwägen Sie, den WordPress-Admin hinter einem VPN oder SSH-Tunnel zu platzieren, anstatt ihn überhaupt dem öffentlichen Internet auszusetzen.

Schutz der Editor-Rolle vor Missbrauch

Die Editor-Rolle ist deutlich sicherer als die Administrator-Rolle, aber nicht ohne Risiko:

• Ein Editor mit unfiltered_html kann Tracking-Pixel, Affiliate-Weiterleitungen oder bösartige Skripte in Beitragsinhalte einschleusen. Bei Multisite wird diese Fähigkeit entfernt — ein starkes Argument für den Betrieb eines Multisite-Netzwerks, wenn Sie viele Content-Mitwirkende haben.
• Ein Editor kann jeden Beitrag oder jede Seite dauerhaft löschen, einschließlich solcher, die er nicht verfasst hat. Es gibt keinen integrierten Papierkorb für Seiten. Verwenden Sie eine Revisions- oder Backup-Strategie, um dies zu mildern.
• Ein Editor kann Kommentare genehmigen, einschließlich solcher mit Spam-Links, was das SEO und den Ruf Ihrer Website beeinträchtigt.

WordPress Multisite: Wie sich Rollen ändern

In einem WordPress Multisite-Netzwerk erhält die Rollenhierarchie eine zusätzliche Ebene: Super Administrator. Der Super Admin steht über allen Administratoren auf Website-Ebene und kontrolliert netzwerkweite Einstellungen, Plugin-Aktivierung auf allen Websites und die Benutzererstellung auf Netzwerkebene.

Bei Multisite verliert ein Administrator auf Website-Ebene mehrere Fähigkeiten, die bei Einzelseiten-Installationen vorhanden sind, einschließlich der Möglichkeit, Plugins zu installieren (nur Super Admins können das netzwerkweit tun) und die unfiltered_html-Fähigkeit. Dies macht Multisite zu einer besser verteidigbaren Architektur für Agenturen, die Kunden-Websites verwalten, oder für Publisher, die mehrere redaktionelle Eigenschaften verwalten.

Wenn Sie eine mandantenfähige Publishing-Plattform aufbauen, kann ein VPS mit cPanel die serverseitige Verwaltungsschicht vereinfachen, während WordPress Multisite die Rollentrennung auf Anwendungsebene übernimmt.

Benutzerdefinierte Rollen: Wenn weder Administrator noch Editor passt

Die add_role()– und add_cap()-Funktionen von WordPress ermöglichen es Ihnen, Rollen mit genau den Fähigkeiten zu definieren, die Ihr Workflow erfordert. Zum Beispiel kann ein Senior Editor, der alles tun kann, was ein Editor tun kann, plus Benutzer verwalten (aber keine Plugins), programmatisch erstellt werden:

add_role(
    'senior_editor',
    'Senior Editor',
    array(
        // Inherit all standard Editor capabilities
        'read'                   => true,
        'edit_posts'             => true,
        'edit_others_posts'      => true,
        'edit_published_posts'   => true,
        'publish_posts'          => true,
        'delete_posts'           => true,
        'delete_others_posts'    => true,
        'delete_published_posts' => true,
        'edit_pages'             => true,
        'edit_others_pages'      => true,
        'edit_published_pages'   => true,
        'publish_pages'          => true,
        'delete_pages'           => true,
        'manage_categories'      => true,
        'moderate_comments'      => true,
        'upload_files'           => true,
        // Extended capability
        'list_users'             => true,
        'edit_users'             => true,
    )
);

Platzieren Sie diesen Code in einem website-spezifischen Plugin (nicht in der functions.php eines Themes), damit die Rolle bei Theme-Wechseln erhalten bleibt. Rollen werden nach der ersten Registrierung in der Datenbank gespeichert, daher muss add_role() nur einmal ausgeführt werden — umschließen Sie es mit einem Plugin-Aktivierungs-Hook unter Verwendung von register_activation_hook().

Praktische Entscheidungsmatrix für die Rollenzuweisung

Verwenden Sie diese Checkliste, bevor Sie eine Rolle zuweisen:

Weisen Sie Administrator nur zu, wenn der Benutzer:

• Die Website besitzt oder eine vertragliche Verantwortung für ihren technischen Betrieb hat
• Plugins und Themes installieren, konfigurieren oder aktualisieren muss
• Andere Benutzerkonten verwalten oder Benutzerrollen ändern muss
• Zugriff auf WordPress-Einstellungen, Permalink-Struktur oder Website-URL benötigt
• Zwei-Faktor-Authentifizierung aktiviert hat und ein einzigartiges, nicht geteiltes Konto verwendet
• Versteht, dass DISALLOW_FILE_MODS in der Produktion auf true gesetzt wird

Weisen Sie Editor zu, wenn der Benutzer:

• Für Inhaltsqualität, Veröffentlichungspläne oder redaktionelle Überprüfung verantwortlich ist
• Beiträge und Seiten verwalten muss, die von anderen Teammitgliedern verfasst wurden
• Kommentare moderieren und Medien verwalten können soll
• Keinen Zugriff auf Plugin-, Theme- oder Einstellungsbildschirme benötigt — und haben sollte
• Ein Kunde, Freiberufler oder Auftragnehmer sein kann, dessen Kontosicherheit Sie nicht vollständig kontrollieren können

Erwägen Sie eine benutzerdefinierte Rolle, wenn:

• Der integrierte Editor zu restriktiv ist (z. B. der Benutzer list_users für ein redaktionelles Workflow-Plugin benötigt)
• Der integrierte Administrator zu permissiv ist (z. B. ein Entwickler, der Plugin-Zugriff benötigt, aber keine Benutzerkonten berühren darf)
• Sie ein Multisite-Netzwerk mit differenzierten Verantwortlichkeiten über Websites hinweg betreiben

Für Teams, die WordPress zusammen mit transaktionalen E-Mails verwalten, erwägen Sie, Ihre Rollenstrategie mit einem dedizierten E-Mail-Hosting-Setup zu kombinieren, damit WordPress-Benachrichtigungs-E-Mails (Passwort-Resets, neue Benutzerregistrierungen, Kommentar-Benachrichtigungen) über einen zuverlässigen, authentifizierten Mail-Server geleitet werden, anstatt über das Standard-Sendmail des Hosting-Servers — ein häufiger Zustellbarkeitsfehler, der den Workflow jeder Rolle beeinträchtigt.

Wenn Ihre WordPress-Website E-Commerce, Mitgliedschaften oder Benutzerdaten verarbeitet, stellen Sie sicher, dass Ihre SSL-Zertifikate aktuell und ordnungsgemäß konfiguriert sind. Ein abgelaufenes Zertifikat beeinträchtigt nicht nur das SEO — es unterbricht den Browser-Sicherheitskontext, der Administrator-Anmeldedaten während der Übertragung schützt.

Wichtige technische Erkenntnisse

• WordPress-Fähigkeiten werden pro Benutzer in wp_usermeta gespeichert, nicht fest codiert — sie können angepasst werden, ohne die angezeigte Rolle eines Benutzers zu ändern.
• DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS in wp-config.php sind auf jeder Produktionswebsite mit mehreren Administratoren nicht verhandelbar.
• Die unfiltered_html-Fähigkeit existiert sowohl für Administratoren als auch für Editoren bei Einzelseiten-Installationen. Multisite entfernt sie von allen unterhalb des Super Admins.
• Ein Editor kann jeden Beitrag oder jede Seite dauerhaft löschen, einschließlich der Inhalte anderer Benutzer. Implementieren Sie eine Backup- oder Revisionsstrategie, bevor Sie diese Rolle an jemanden außerhalb Ihres Kernteams vergeben.
• Verwenden Sie niemals ein gemeinsam genutztes Administrator-Konto. Ein Konto pro Person, Zwei-Faktor-Authentifizierung obligatorisch und Audit-Protokolle über ein Plugin wie WP Activity Log aktiviert.
• Benutzerdefinierte Rollen über add_role() sind die richtige Lösung, wenn keine Standardrolle passt — überprivilegieren Sie nicht, um eine fehlende Fähigkeit zu kompensieren.
• Bei Multisite können Administratoren auf Website-Ebene keine Plugins installieren. Dies ist eine Funktion, keine Einschränkung — es ist die richtige Architektur für verwaltete mandantenfähige Umgebungen.

Häufig gestellte Fragen

Kann ein Editor die Beiträge eines anderen Benutzers in WordPress löschen?

Ja. Die Editor-Rolle umfasst delete_others_posts und delete_others_pages. Ein Editor kann jeden Beitrag oder jede Seite auf der Website dauerhaft löschen, unabhängig davon, wer ihn verfasst hat. Es gibt keinen integrierten Bestätigungsschritt oder Papierkorb für Seiten, daher ist diese Aktion ohne ein Backup nicht rückgängig zu machen.

Was ist der Unterschied zwischen Administrator und Super Administrator in WordPress?

Bei einer WordPress-Einzelseiten-Installation ist Administrator die höchste Rolle. In einem WordPress Multisite-Netzwerk steht der Super Administrator über allen Administratoren auf Website-Ebene und kontrolliert netzwerkweite Einstellungen, Plugin-Installation auf allen Websites und die Möglichkeit, Websites zum Netzwerk hinzuzufügen oder daraus zu entfernen. Ein Administrator auf Website-Ebene bei Multisite kann keine Plugins installieren oder unfiltered_html verwenden.

Kann ich einem Editor Zugriff auf die Einstellungen eines bestimmten Plugins geben, ohne ihn zum Administrator zu machen?

Ja. Verwenden Sie add_cap(), um einem einzelnen Benutzer eine bestimmte Fähigkeit zu gewähren, oder erstellen Sie eine benutzerdefinierte Rolle, die die Standardfähigkeiten des Editors plus die spezifische Fähigkeit enthält, die das Plugin registriert. Die meisten gut codierten Plugins verwenden current_user_can( 'manage_options' ) oder eine benutzerdefinierte Fähigkeit für ihre Einstellungsseiten — überprüfen Sie den Quellcode des Plugins, um die genaue erforderliche Fähigkeit zu identifizieren.

Ist es sicher, mehrere Administratoren auf einer WordPress-Website zu haben?

Es hängt vollständig von Ihren Betriebskontrollen ab. Mehrere Administratoren vervielfachen die Angriffsfläche — jedes Konto ist ein potenzieller Einstiegspunkt. Wenn mehrere Administratoren notwendig sind, erzwingen Sie Zwei-Faktor-Authentifizierung für alle, beschränken Sie den /wp-admin/-Zugriff nach IP auf Serverebene, setzen Sie DISALLOW_FILE_MODS auf true und verwenden Sie ein Aktivitätsprotokoll-Plugin, um alle administrativen Aktionen zu prüfen.

Wie prüfe ich, welche Fähigkeiten ein bestimmter WordPress-Benutzer tatsächlich hat?

Fragen Sie die Datenbank direkt ab oder verwenden Sie ein Plugin wie Members oder User Role Editor. Für eine programmatische Überprüfung verwenden Sie get_user_meta( $user_id, $wpdb->prefix . 'capabilities', true ) in einem benutzerdefinierten Skript oder der WordPress CLI:

wp user get <user_id> --field=roles
wp user list-caps <user_id>

Der wp user list-caps-Befehl gibt jede Fähigkeit aus, die der Benutzer besitzt, einschließlich solcher, die individuell außerhalb seiner zugewiesenen Rolle gewährt wurden — was die zuverlässigste Methode zur Prüfung überprivilegierter Konten ist.