WordPress-bestandsrechten: 755, 644, wp-config.php en eigenaar

Dit artikel is een gelokaliseerde versie van het Japanse origineel. Lees het Japanse origineel

Voor WordPress-bestanden geldt als basis: mappen op 755 en bestanden op 644. Bij wp-config.php, dat de verbindingsgegevens voor de database bevat, beperk je verder wie het mag lezen. Kijk niet alleen naar de cijfers, maar controleer ook wie de eigenaar van de bestanden is en met welke gebruiker PHP draait. Zo voorkom je zowel lekken van gegevens als het probleem dat je niet kunt updaten. De aanbevolen waarden in dit artikel komen uit "Hardening WordPress" in de officiële WordPress-documentatie, zoals gecontroleerd in november 2026.

Zo lees je de cijfers van bestandsrechten

Bestandsrechten gelden voor drie groepen: eigenaar, groep en overigen. Per groep tel je lezen (4), schrijven (2) en uitvoeren (1) op.

Het recht "uitvoeren" (x) bij een map is het recht om die map te openen. Haal je x bij een map weg, dan kunnen de bestanden erin niet meer worden gelezen.

Aanbevolen waarden voor WordPress

Je hoeft niets op 777 (voor iedereen schrijfbaar) te zetten. Op een gedeelde server kan een andere gebruiker van dezelfde server dan je bestanden herschrijven.

Sommige hostingbedrijven in Japan hebben eigen aanbevolen waarden (omdat PHP per server anders wordt uitgevoerd). Staan er waarden in de handleiding van je server, dan gaan die voor.

Hoe je over de eigenaar moet denken

Volgens de officiële uitleg zijn de bestanden eigendom van je eigen gebruikersaccount en kun jij erin schrijven. Alleen bestanden waarin WordPress moet kunnen schrijven (uploads, en thema's als je de themabestandseditor gebruikt) laat je schrijfbaar zijn voor de gebruiker waarmee de webserver (PHP) draait, door de eigenaar of de groep daarop af te stemmen.

Maak je alles eigendom van de gebruiker van de webserver, bijvoorbeeld met chown -R www-data:www-data, dan kan PHP alle bestanden herschrijven. Bij misbruik van een kwetsbaarheid in een plugin is de schade dan groter, dus controleer eerst de huidige situatie voordat je beslist.

Als bij een update van een plugin of de kern om "verbindingsgegevens (hostnaam, gebruikersnaam en wachtwoord voor FTP)" wordt gevraagd, komt dat meestal doordat de eigenaars niet overeenkomen. WordPress kiest alleen voor het rechtstreeks herschrijven van bestanden als de eigenaar van een door PHP aangemaakt bestand dezelfde is als de eigenaar van de WordPress-bestanden. Is dat niet zo, dan vraagt het om een update via FTP. Verruim niet de rechten naar 777, maar los het op door de eigenaars op elkaar af te stemmen.

De huidige instellingen controleren

Ga via SSH naar de WordPress-map en controleer met de volgende opdrachten de waarden en de eigenaar. Pas de paden aan je eigen omgeving aan.

cd /var/www/html

# Rechten, eigenaar en groep van wp-config.php
stat -c '%a %U:%G %n' wp-config.php

# Zoek bestanden en mappen waarin andere gebruikers kunnen schrijven
find . -perm -o=w ! -type l

# Zoek PHP-bestanden in uploads (die horen er normaal niet te zijn)
find wp-content/uploads -type f -name '*.php'

De gebruiker waarmee PHP draait bij een verzoek via het web controleer je in de serverinstellingen (bijvoorbeeld user in de pool van PHP-FPM) of in de handleiding van de hostingprovider. Dat hoeft niet dezelfde gebruiker te zijn als waarmee je via SSH inlogt.

Staat er in uploads een PHP-bestand dat je niet herkent, vermoed dan manipulatie en noteer de datum en inhoud van het bestand voordat je het verwijdert.

De rechten in één keer herstellen

Voer dit uit in de WordPress-map. Maak vóór het uitvoeren een back-up.

cd /var/www/html

# Zet mappen op 755 en bestanden op 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# Beperk wp-config.php (voorbeeld voor een omgeving waarin PHP als eigenaar van het bestand draait)
chmod 600 wp-config.php

De waarde voor wp-config.php kies je afhankelijk van je omgeving.

• PHP draait als dezelfde gebruiker als de eigenaar van het bestand (veel gedeelde hostingpakketten, PHP-FPM per gebruiker): 600 of 400
• De eigenaar is je eigen account en de webserver leest het bestand als groep: 640 of 440, met de groep van de webserver als groep

# Voorbeeld: jijzelf als eigenaar, de webserver (www-data) als groep, met 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php

Open na het instellen de site en het beheer en controleer of de weergave en het inloggen werken. Zie je een wit scherm of een foutmelding, dan kan PHP wp-config.php niet lezen. Zet de waarde terug naar 644 en bekijk daarna de eigenaar en de groep opnieuw.

Bij 400 of 440 mislukken plugins die in wp-config.php schrijven (bijvoorbeeld plugins die cache-instellingen daarin wegschrijven). Sta schrijven alleen tijdelijk toe wanneer je zo'n plugin instelt.

Zorg dat wp-config.php niet via het web kan worden gelezen

Draait PHP normaal, dan wordt de inhoud niet getoond als je wp-config.php in de browser opent. Om te voorkomen dat de broncode zichtbaar wordt als PHP stopt, weiger je de toegang ook aan de kant van de webserver. Bij Apache 2.4 zet je het volgende in de .htaccess in de map waarin WordPress staat (de oude Order Deny,Allow / Deny from all is de notatie van Apache 2.2).

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

De gedetailleerde stappen staan in "Toegang tot wp-config.php weigeren".

De toegang tot .htaccess zelf wordt al geweigerd door de standaardinstellingen van Apache (<Files ".ht*"> in httpd.conf).

Volgens de officiële uitleg kun je wp-config.php ook één map hoger zetten dan de map waarin WordPress staat. Staat er in dezelfde map geen wp-config.php, dan zoekt WordPress in de map erboven. De officiële uitleg vermeldt echter ook de mening dat het effect klein is en dat het gevaarlijker kan worden als je het verkeerd doet. Verplaats je het, controleer dan dat de map erboven geen openbare map is.

Geen PHP uitvoeren in uploads

uploads is een map waarin WordPress schrijft en een plek waar bij een aanval gemakkelijk bestanden worden geplaatst. Zorg dat PHP hier niet wordt uitgevoerd, dan werkt een geplaatst bestand niet.

Bij Apache 2.4 maak je wp-content/uploads/.htaccess aan en schrijf je het volgende.

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

Om Require in .htaccess te kunnen gebruiken, moet dat aan de serverkant zijn toegestaan met AllowOverride. Is het niet toegestaan, dan krijg je een 500-fout of wordt de instelling genegeerd. Open na het schrijven een niet-bestaande PHP-URL zoals https://example.com/wp-content/uploads/test.php en controleer of je een 403 krijgt (blijft het 404, dan werkt de instelling niet).

Bij Nginx zet je het volgende in het server-blok, vóór de location ~ \.php$ die PHP verwerkt. Locations met een reguliere expressie worden van boven naar beneden vergeleken en de eerste die overeenkomt wordt gebruikt.

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

Controleer na het wijzigen van de configuratie de syntaxis met nginx -t en laad daarna opnieuw.

Overigens accepteert het uploaden van media in WordPress standaard alleen toegestane soorten bestanden (afbeeldingen, PDF's en dergelijke). Een PHP-bestand als media uploaden kan vanuit het beheer normaal gesproken niet.

Aandachtspunten

• Maak vóór het wijzigen van rechten een back-up van de bestanden en de database.
• Als je rechten via een FTP-programma wijzigt, ondersteunen sommige servers het in één keer wijzigen niet. Zijn het veel bestanden, dan is find via SSH sneller en mis je minder.
• Wordt er bij een update om verbindingsgegevens voor FTP gevraagd, verruim dan niet de rechten maar controleer de eigenaar. Zie ook "Zo los je rechtenfouten in WordPress op".
• Voer de bovenstaande controleopdrachten (bestanden waarin andere gebruikers kunnen schrijven, PHP in uploads) regelmatig uit, dan merk je eerder dat instellingen zijn ontspoord of dat er is geknoeid.

Vragen over WordPress? De uitgever van deze site zit in Japan en antwoordt in het Japans. Contact (Japans)