Premium WordPress-Wartung · by Frontend GmbH
Sollten Dateiänderungen im WordPress-Backend deaktiviert werden?
Die Antwort.
Der integrierte Theme- und Plugin-Dateieditor sollte auf betreuten Unternehmenswebsites in der Regel deaktiviert werden. Änderungen erfolgen dann nachvollziehbar über sichere Datei- oder Deploymentwege und sind weniger leicht über ein kompromittiertes Admin-Konto missbrauchbar.
Sofern ausdrücklich vereinbart, deaktivieren wir den integrierten Dateieditor Ihrer Website in der Regel und nutzen nachvollziehbare Änderungswege.
Der Backend-Editor ist kein geeigneter Deployment-Weg
Wer bereits Administratorzugriff hat, könnte über den Editor ausführbaren Code verändern. Seine Abschaltung beseitigt nicht alle Adminrisiken, entfernt aber einen einfachen Weg.
- DISALLOW_FILE_EDIT kontrolliert in der Konfiguration setzen.
- Codeänderungen über versionierte und prüfbare Prozesse ausrollen.
- Plugin- und Theme-Installation separat nach Bedarf begrenzen.
- Dateirechte und Administratorzugänge weiterhin absichern.
Dateieditor und Updateinstallation sind nicht dasselbe
DISALLOW_FILE_EDIT sperrt den eingebauten Codeeditor, verhindert aber nicht zwingend Plugin- oder Theme-Installationen. Dafür existieren weitergehende Konfigurations- und Berechtigungsoptionen, die sorgfältig zum Updateprozess passen müssen. Wird alles pauschal gesperrt, kann auch die geregelte Wartung blockiert werden. Ziel ist ein kontrollierter Deploymentweg, nicht bloß eine möglichst harte Schalterstellung.
Dateieditor und Softwareinstallation sind verschiedene Schalter
DISALLOW_FILE_EDIT sperrt den integrierten Theme- und Plugin-Codeeditor. Installation und Updates können trotzdem möglich bleiben. Weitergehende Einschränkungen müssen zum geregelten Wartungs- und Deploymentweg passen.
Ziel ist, spontane Codeänderung im Backend zu verhindern und Änderungen versioniert sowie prüfbar auszurollen. Dateirechte und starke Adminzugänge bleiben nötig, weil ein kompromittierter Administrator andere Änderungswege besitzen kann. Nach der Konfiguration werden geplante Updates getestet, damit Härtung nicht die Pflege blockiert.
Änderungsweg außerhalb des Backends festlegen
Die Einstellung wird in der Konfiguration außerhalb des öffentlichen Webzugriffs dokumentiert. Wer sie ändern darf, folgt dem Deploymentprozess. Bei Störungen bleibt der Editor nicht der spontane Reparaturweg; Änderungen werden lokal oder auf einer Testumgebung vorbereitet und kontrolliert übertragen.
Verwandte Fragen.
Sollte XML-RPC deaktiviert werden?
XML-RPC sollte nur deaktiviert oder eingeschränkt werden, wenn keine benötigte Funktion davon abhängt.
Muss jedes Plugin mit Sicherheitslücke sofort deaktiviert werden?
Nein, ein Plugin mit Sicherheitslücke muss nicht in jedem Fall sofort deaktiviert werden; entscheidend sind betroffene Version, Ausnutzbarkeit und Exponierung auf Ihrer Website.
Wie wird ein Sicherheitsnotfall in der Kunden-App dokumentiert?
Ein Sicherheitsnotfall Ihrer Website wird in der Kunden-App als Incident mit Zeitpunkt, Beschreibung, Status, Anhängen und Bearbeitungsverlauf dokumentiert.
Welche Verantwortung bleibt beim Unternehmen?
Beim Unternehmen bleiben geschäftliche Entscheidungen, sichere Endgeräte und E-Mail-Konten, Benutzerfreigaben, Lizenz- und Datenschutzpflichten sowie die Information über Änderungen durch andere Dienstleister.
Ihre Website-Betreuung klären.
Beschreiben Sie uns Ihre Website und Ihr Anliegen. Im Gespräch legen wir fest, welche Betreuung Sie benötigen.