Warum WordPress-Plugin-Sicherheit immer wieder scheitert – und was EmDash ändert
WordPress-Plugin-Risiko ist nicht nur ein Qualitätsproblem, sondern ein Ausführungsmodell-Problem. EmDash ändert das Vertrauensmodell durch Isolation und nur deklarierte Capabilities.
Über WordPress-Plugin-Sicherheit wird oft so gesprochen, als läge das Hauptproblem an schlechtem Code, aufgegebenen Maintainern oder inkonsistentem Review. Das ist real – steht aber unterhalb einer grundlegenderen Designentscheidung: Ein WordPress-Plugin läuft meist mit weit mehr Autorität, als es sollte.
Eine Plugin-Schwachstelle bleibt daher selten auf ein kleines Feature beschränkt. Sie kann site-weit werden, weil das Plugin in derselben breiten Ausführungsumgebung wie der Rest der Anwendung läuft.
Warum sich das Problem wiederholt
Das WordPress-Plugin-Ökosystem ist riesig, weil WordPress Erweiterung einfach machte. Diese Offenheit schuf enormen Wert – und ein Sicherheitsmodell auf tiefem Vertrauen.
Praktisch bedeutet Plugin-Installation oft Vertrauen mit:
- Datenbankzugriff
- Dateisystemzugriff
- breiten Ausführungs-Hooks
- indirekter Exposition gegenüber beliebigem Input von Nutzern, Bots und anderen Plugins
Sicherheit wird dann zur Hoffnung, jeder Autor treffe für immer gute Entscheidungen. Für ein großes Ökosystem ist das keine skalierbare Annahme.
Das eigentliche Problem ist Über-Berechtigung
Ein Plugin soll keine breite Autorität bekommen, nur weil es eine enge Aufgabe erfüllt.
Wenn ein Plugin nach Veröffentlichung eines Beitrags E-Mail sendet, ist die wichtige Frage nicht die Popularität des Plugins, sondern was es wirklich tun darf.
Ein modernes Sicherheitsmodell sollte einer Administration Fragen beantwortbar machen wie:
- Kann dieses Plugin Inhalte lesen?
- Kann es Inhalte schreiben?
- Kann es E-Mail senden?
- Kann es externe Dienste aufrufen?
- Kann es außerhalb des deklarierten Umfangs etwas berühren?
WordPress wurde nicht um solche expliziten Berechtigungsgrenzen herum entworfen.
Was EmDash ändert
EmDash geht anders vor. Plugins laufen in isolierten Sandboxes und sollen ihre Capabilities vorab deklarieren.
Das verschiebt Vertrauen von vager Reputation zu sichtbarem Umfang.
Ein besseres Plugin-System verspricht nicht perfekte Autoren. Es begrenzt die Auswirkungen, wenn Autoren Fehler machen.
Mit explizitem Capability-Modell lässt sich Plugin-Risiko direkter begründen:
- ein Content-Automatisierungs-Plugin kann auf Content-Hooks und Lesezugriff begrenzt werden
- eine E-Mail-Integration kann auf Versand begrenzt werden
- Netzwerkzugriff kann auf bestimmte Ziele statt pauschal angenommen werden
Das passt besser zu Teams mit Security-Review statt Plugin-Popularity-Contest.
Warum das für echten CMS-Betrieb zählt
Die meisten Content-Teams haben keine Zeit, jedes Plugin tief zu auditieren. Sie brauchen trotzdem Integrationen, Automatisierungen, Previews, Benachrichtigungen und Workflows. Die praktische Frage ist, ob die Plattform ein sinnvolles Standard-Vertrauensmodell liefert.
Hier ist EmDash stärker: Statt jedem Plugin breiten Zugang zu unterstellen, startet es umgekehrt – Zugang soll bewusst und eng gewährt werden.
Das ersetzt Review nicht, macht es aber sinnvoller.
Die Kernaussage
Das WordPress-Plugin-Sicherheitsproblem sind nicht nur unsichere Plugins. Es ist ein Ökosystem, in dem Plugins mit zu viel Vertrauen starten.
EmDash löst das nicht allein durch Appell an besseres Verhalten. Es ändert das Ausführungsmodell:
- Plugins isolieren
- Capabilities deklarieren
- nur gewähren, was nötig ist
- Folgen von Plugin-Fehlern reduzieren
Das ist der Unterschied zwischen einem Plugin-System, das auf Hoffnung setzt, und einem, das auf Beschränkung gebaut ist.