WordPress-Dateirechte: Empfehlung 755/644, wp-config.php, Besitzer

Dieser Artikel ist eine lokalisierte Fassung des japanischen Originals. Japanisches Original lesen

Bei den Dateirechten von WordPress gilt grundsätzlich: Verzeichnisse erhalten 755, Dateien 644. Die Datei wp-config.php, die die Zugangsdaten der Datenbank enthält, schränken Sie noch weiter ein. Prüfen Sie nicht nur die Zahlen, sondern auch, wem die Dateien gehören und unter welchem Benutzer PHP läuft. So verhindern Sie sowohl Datenlecks als auch das Problem, dass sich nichts mehr aktualisieren lässt. Die Empfehlungen in diesem Artikel entsprechen dem Stand der offiziellen WordPress-Seite „WordPress härten (Hardening WordPress)“ im November 2026.

So lesen Sie die Zahlen der Dateirechte

Dateirechte bestehen aus drei Gruppen: „Besitzer, Gruppe, Andere“. Sie werden als Summe aus Lesen (4), Schreiben (2) und Ausführen (1) angegeben.

Das „Ausführen (x)“ bei einem Verzeichnis bedeutet das Recht, das Verzeichnis zu betreten. Wenn Sie bei einem Verzeichnis x entfernen, lassen sich die darin liegenden Dateien nicht mehr lesen.

Empfohlene Werte für WordPress

777 (für alle beschreibbar) ist nicht nötig. Auf einem Shared Server könnten andere Nutzer desselben Servers die Dateien überschreiben.

Manche Mietserver legen eigene empfohlene Werte fest (weil PHP von Server zu Server unterschiedlich betrieben wird). Stehen im Handbuch Ihres Servers Werte, haben diese Vorrang.

Wie Sie mit dem Besitzer umgehen

Laut offizieller Beschreibung gehören die Dateien Ihrem eigenen Benutzerkonto und sind für Sie beschreibbar. Nur Dateien, in die WordPress schreiben muss (uploads, bei Nutzung des Theme-Editors die Themes usw.), stimmen Sie bei Besitzer oder Gruppe so ab, dass der Benutzer, unter dem der Webserver (PHP) läuft, schreiben kann.

Wenn Sie alles per chown -R www-data:www-data dem Benutzer des Webservers übertragen, kann PHP sämtliche Dateien überschreiben. Wird dann eine Schwachstelle in einem Plugin ausgenutzt, wächst der Schaden leichter. Prüfen Sie daher zuerst den Ist-Zustand und entscheiden Sie dann.

Dass bei Plugin- oder Core-Updates nach „Verbindungsdaten (FTP-Hostname, Benutzername, Passwort)“ gefragt wird, liegt meist an einem solchen abweichenden Besitzer. WordPress wählt nur dann das direkte Überschreiben der Dateien, wenn der Besitzer der von PHP erzeugten Dateien und der Besitzer der WordPress-Dateien übereinstimmen. Andernfalls verlangt es ein Update über FTP. Setzen Sie die Dateirechte nicht auf 777 herauf, sondern korrigieren Sie den Besitzer.

Die aktuelle Einstellung prüfen

Wechseln Sie per SSH in das WordPress-Verzeichnis und prüfen Sie Werte und Besitzer mit den folgenden Befehlen. Passen Sie den Pfad an Ihre Umgebung an.

cd /var/www/html

# Wert, Besitzer und Gruppe von wp-config.php
stat -c '%a %U:%G %n' wp-config.php

# Dateien und Verzeichnisse suchen, die andere Benutzer beschreiben können
find . -perm -o=w ! -type l

# PHP-Dateien in uploads suchen (gibt es normalerweise nicht)
find wp-content/uploads -type f -name '*.php'

Den Benutzer, unter dem PHP beim Webzugriff läuft, finden Sie in der Serverkonfiguration (z. B. user im PHP-FPM-Pool) oder im Handbuch des Mietservers. Er muss nicht mit dem Benutzer Ihres SSH-Logins übereinstimmen.

Finden Sie in uploads eine PHP-Datei, die Sie nicht kennen, gehen Sie von einer Manipulation aus und notieren Sie vor dem Löschen Datum und Inhalt der Datei.

Dateirechte auf einmal korrigieren

Führen Sie dies im WordPress-Verzeichnis aus. Legen Sie vorher eine Sicherung an.

cd /var/www/html

# Verzeichnisse auf 755, Dateien auf 644 vereinheitlichen
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# wp-config.php einschränken (Beispiel für eine Umgebung, in der PHP unter dem Dateibesitzer läuft)
chmod 600 wp-config.php

Den Wert für wp-config.php wählen Sie je nach Umgebung wie folgt.

• PHP läuft unter demselben Benutzer wie der Dateibesitzer (viele Shared-Mietserver, PHP-FPM pro Benutzer): 600 oder 400
• Der Besitzer ist Ihr eigenes Konto, und der Webserver liest über die Gruppe: 640 oder 440, mit der Gruppe des Webservers als Gruppe

# Beispiel: Besitzer sind Sie selbst, Gruppe ist der Webserver (www-data), Wert 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php

Öffnen Sie nach der Einstellung die Website und den Admin-Bereich und prüfen Sie, ob Anzeige und Login funktionieren. Erscheint ein weißer Bildschirm oder ein Fehler, kann PHP wp-config.php nicht lesen. Setzen Sie den Wert zurück auf 644 und prüfen Sie dann Besitzer und Gruppe.

Bei 400 oder 440 schlagen Plugins fehl, die in wp-config.php schreiben (etwa solche, die Cache-Einstellungen hineinschreiben). Erlauben Sie das Schreiben nur vorübergehend, wenn Sie solche Plugins konfigurieren.

wp-config.php vor dem Lesen über das Web schützen

Läuft PHP einwandfrei, wird der Inhalt von wp-config.php auch beim Aufruf im Browser nicht angezeigt. Damit der Quelltext nicht sichtbar wird, falls PHP ausfällt, verweigern Sie den Zugriff zusätzlich auf Webserver-Ebene. Bei Apache 2.4 schreiben Sie Folgendes in die .htaccess des Verzeichnisses, in dem WordPress liegt (die alte Schreibweise Order Deny,Allow / Deny from all stammt aus Apache 2.2).

<Files "wp-config.php">
    Require all denied
</Files>

Eine ausführliche Anleitung finden Sie unter „Den Zugriff auf wp-config.php verweigern“.

Die .htaccess selbst ist durch die Standardkonfiguration von Apache (<Files ".ht*"> in der httpd.conf) bereits vor Zugriffen geschützt.

Laut offizieller Beschreibung können Sie wp-config.php auch ein Verzeichnis oberhalb des WordPress-Verzeichnisses verschieben. WordPress sucht ein Verzeichnis höher, wenn im selben Verzeichnis keine wp-config.php liegt. Die offizielle Seite weist jedoch darauf hin, dass manche den Nutzen für gering halten und dass es bei falscher Umsetzung sogar gefährlich werden kann. Wenn Sie die Datei verschieben, stellen Sie sicher, dass das übergeordnete Verzeichnis kein öffentliches Verzeichnis ist.

PHP in uploads nicht ausführen lassen

uploads ist ein Verzeichnis, in das WordPress schreibt, und deshalb eine Stelle, an der Angreifer leicht Dateien ablegen. Wenn dort kein PHP ausgeführt wird, bleiben abgelegte Dateien wirkungslos.

Bei Apache 2.4 legen Sie wp-content/uploads/.htaccess an und schreiben Folgendes hinein.

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Damit Require in der .htaccess funktioniert, muss es serverseitig über AllowOverride erlaubt sein. Ist es nicht erlaubt, gibt es einen 500-Fehler, oder die Einstellung wird ignoriert. Rufen Sie nach dem Eintragen eine nicht vorhandene PHP-URL wie https://example.com/wp-content/uploads/test.php auf und prüfen Sie, dass 403 erscheint (bleibt es bei 404, greift die Einstellung nicht).

Bei Nginx setzen Sie im server-Block Folgendes vor die location ~ \.php$, die PHP verarbeitet. Reguläre location-Ausdrücke werden von oben nach unten geprüft, und es gilt der erste Treffer.

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Nach einer Änderung prüfen Sie die Syntax mit nginx -t und laden die Konfiguration dann neu.

Übrigens nimmt der Medien-Upload von WordPress standardmäßig nur erlaubte Dateitypen (Bilder, PDF usw.) an. PHP-Dateien als Medien hochzuladen, ist über den Admin-Bereich normalerweise nicht möglich.

Hinweise

• Legen Sie vor jeder Änderung der Dateirechte eine Sicherung der Dateien und der Datenbank an.
• Beim Ändern der Dateirechte mit einem FTP-Programm unterstützen manche Server keine Änderung im Stapel. Bei vielen Dateien geht es per find über SSH schneller, und es verhindert, dass etwas übersehen wird.
• Wird beim Update nach FTP-Verbindungsdaten gefragt, erweitern Sie nicht die Dateirechte, sondern prüfen den Besitzer. Hilfreich ist auch „WordPress-Fehler bei den Dateirechten beheben“.
• Führen Sie die obigen Prüfbefehle (für andere beschreibbare Dateien, PHP in uploads) regelmäßig aus, um Fehlkonfigurationen und Manipulationen früh zu bemerken.

Fragen zu WordPress? Der Betreiber dieser Seite sitzt in Japan und antwortet auf Japanisch. Kontakt (Japanisch)