Legen Sie Eigentümer und Berechtigungen entsprechend dem Hosting-Modell so fest, dass der Webserver nur dort schreibt, wo es nötig ist. Schützen Sie wp-config.php und Geheimnisse außerhalb eines öffentlichen Repositorys, deaktivieren Sie die Code-Bearbeitung im Admin-Bereich und deployen Sie versionierten Code über einen kontrollierten Prozess. Überprüfen Sie jede Änderung stets mit Upload, Cache und Update.
Die Dateiberechtigungen in WordPress legen fest, welcher Serverbenutzer Code und Daten lesen oder ändern darf. Zu offene Rechte erleichtern das Schreiben einer schädlichen Datei, zu strenge blockieren Uploads, Cache oder Updates. Eine universelle numerische Anleitung ohne Kenntnis des Hostings ist gefährlich, da sich das Eigentümermodell zwischen Shared Hosting, Container und verwaltetem Server unterscheidet.
Ein sensibler Bestandteil ist `wp-config.php`, in der sich Datenbank-Zugangsdaten, Sicherheitsschlüssel und Umgebungseinstellungen befinden. Geheimnisse gehören weder in ein Repository noch in ein über das Web zugängliches Backup oder einen Support-Screenshot. Ein sicheres Konzept trennt unveränderlichen Code, beschreibbare Uploads, temporären Cache und Konfiguration und gibt jedem Prozess nur den erforderlichen Umfang.
Ermitteln Sie die Benutzer und Prozesse des Servers
Ermitteln Sie vor einer Änderung den Eigentümer der Dateien, den PHP- oder Webserver-Benutzer, das Deployment-Konto und die Gruppen. Auf Shared Hosting kann der Anbieter ein anderes Modell verwenden als auf einem eigenen VPS. Prüfen Sie die Dokumentation und die aktuellen Berechtigungen, nicht einen beliebigen Befehl aus einem Forum. Halten Sie fest, in welche Verzeichnisse WordPress im regulären Betrieb schreiben muss.
Unterscheiden Sie das interaktive Konto eines Administrators von einer Anwendung. Ein FTP-Konto mit Zugriff auf alles sollte nicht in einem WordPress-Plugin gespeichert sein. Jedes Automatisierungskonto erhält einen eigenen Schlüssel und ein minimal notwendiges Verzeichnis. Unterstützt das Hosting kein sicheres Modell oder keine Isolierung benachbarter Websites, hat eine technische Änderung der Rechte in einer einzelnen Installation nur begrenzte Wirkung.
Trennen Sie Code von beschreibbaren Daten
Core, Themes und Plugins sollten im laufenden Betrieb unveränderlich sein, wenn Updates über einen kontrollierten Prozess ausgerollt werden. Uploads, Cache und einige temporäre Verzeichnisse benötigen Schreibzugriff. Kann der Webserver das gesamte Document Root ändern, überschreibt eine Schwachstelle der Anwendung leichter den Code. Die Hosting- und Deployment-Architektur sollte die beschreibbare Fläche begrenzen.
Schützen Sie das Upload-Verzeichnis je nach den Möglichkeiten des Servers vor der Ausführung von Skripten und validieren Sie die hochgeladenen Dateitypen. Der Cache muss sich sicher leeren lassen, ohne den Eigentümer zu ändern. Speichern Sie Logs außerhalb des öffentlichen Pfads oder sperren Sie den Zugriff darauf. Prüfen Sie nach einer Migration, ob das Kopieren den Eigentümer nicht verändert und keine weltweit beschreibbaren Dateien erzeugt hat.
- Unveränderlicher Kern, Themes und Plugins
- Schreibzugriff nur auf Uploads und den nötigen Cache
- Nicht ausführbare Benutzer-Uploads
- Logs außerhalb des öffentlichen Zugriffs
Schützen Sie wp-config.php und Geheimnisse
Eine Konfigurationsdatei sollte nur von den Prozessen lesbar sein, die sie benötigen, und kann je nach Architektur außerhalb des öffentlichen Stammverzeichnisses liegen. Legen Sie keine Produktionsdaten in einem öffentlichen Git-Repository ab. Ein modernes Deployment kann Geheimnisse aus der Umgebung oder einem sicheren Speicher laden, muss aber ein dokumentiertes Verfahren für die lokale Entwicklung und die Wiederherstellung haben.
Der Datenbankbenutzer erhält nur die für WordPress erforderlichen Rechte sowie separate Zugangsdaten für jede Umgebung. Rotieren Sie Sicherheits-Salts und API-Schlüssel bei Verdacht oder bei Änderungen gemäß dem festgelegten Prozess; die Rotation der Sitzungen kann Benutzer abmelden, was eine erwartete Auswirkung ist. Debug-Einstellungen in der Produktion dürfen keine Fehler anzeigen und keine sensiblen Ausgaben in einem öffentlich zugänglichen Pfad speichern.
Beschränken Sie die Codebearbeitung aus der Administration
Der Datei-Editor für Themes und Plugins in der Administration ermöglicht sofortige Eingriffe ohne Review, Backup und Test. Im Produktivbetrieb deaktivieren Sie ihn in der Regel über eine Konfigurationseinstellung. Erwägen Sie je nach Art der Verwaltung auch ein Verbot von Installationen und automatischen Eingriffen; Updates müssen dann tatsächlich über einen anderen funktionierenden Prozess erfolgen und dürfen nicht einfach ausbleiben.
Versionieren und prüfen Sie Code und stellen Sie ihn über eine Staging-Umgebung mit Rücksetzmöglichkeit bereit. Ein WordPress-Administrator sollte nicht automatisch SSH oder das Hosting-Panel benötigen. Getrennte Konten verringern die Auswirkungen einer gestohlenen Sitzung. Dokumentieren Sie Notfalleingriffe und gleichen Sie die Produktion nach einem Vorfall mit dem Repository ab, damit die Korrektur beim nächsten Release nicht verloren geht.
- Deaktivierter Code-Editor in der Administration
- Versioniertes und kontrolliertes Deployment
- Getrennte WordPress- und Hosting-Konten
- Abgleich eines Notfall-Fixes mit dem Repository
Testen Sie Berechtigungen nach Änderungen und überwachen Sie die Integrität
Laden Sie nach der Änderung ein Bild hoch, generieren Sie Thumbnails, leeren Sie den Cache, führen Sie ein sicheres Update auf Staging durch und prüfen Sie das Backup. Überwachen Sie PHP- und Server-Logs auf den Fehler „permission denied“. Führen Sie in der Produktion kein rekursives chmod ohne genaue Liste der Ziele und Überprüfung des absoluten Pfads aus; es kann Geheimnisse und sogar ganze benachbarte Anwendungen verändern.
Integritätsmonitoring kann auf Codeänderungen außerhalb eines Releases hinweisen, benötigt jedoch eine Baseline und Ausnahmen für legitime Updates. Eine neue PHP-Datei in den Uploads oder eine unerwartete Änderung am Core ist ein Grund zur Prüfung, kein automatischer Beweis für einen Angriff. Sichern Sie bei einem Vorfall eine Kopie, finden Sie den Einstiegspunkt und stellen Sie einen sauberen Zustand wieder her; eine bloße Korrektur der Berechtigungen entfernt keine Hintertür.
Häufige Fragen
Welcher chmod-Wert ist für WordPress richtig?
Ohne Kenntnis von Eigentümerschaft, Webserver und Hosting lässt sich nicht sicher eine einzige Zahl für alles empfehlen. Nutzen Sie die Dokumentation des Anbieters und das Prinzip der minimalen Rechte und unterscheiden Sie zwischen Dateien, Verzeichnissen, Konfiguration und beschreibbaren Uploads.
Sollte der Webserver in Plugins und Themes schreiben dürfen?
Wenn WordPress Updates direkt durchführt, benötigt es vorübergehend die entsprechenden Rechte. Bei einem gesteuerten Deployment kann der Code unveränderlich bleiben und nur in Datenverzeichnisse geschrieben werden. Das Modell muss über einen funktionierenden Update-Prozess verfügen.
Reicht es, wp-config.php oberhalb von public_html zu verschieben?
Das kann bei einer unterstützten Struktur eine nützliche Ebene sein, ersetzt aber keine korrekten Rechte, sicheren Geheimnisse, Hosting-Isolation und Updates. Prüfen Sie, dass der Server die Datei lädt und die Backups sie sicher enthalten.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
