Kort gezegd: Voor bestandsrechten op de webserver geldt één grondregel: de gebruiker waaronder PHP draait, mag de eigen code lezen maar niet wijzigen. Schrijfrechten krijgen alleen upload-, cache- en tmp-mappen, en daar wordt geen PHP uitgevoerd. Rechten als 777 horen op een productieserver niet thuis.
Waarom bestandsrechten na een inbraak het verschil maken
Als aanvallers via een kwetsbaarheid code op een server uitvoeren, draait die code met de rechten van het PHP-proces. Wat die gebruiker mag, mag ook de aanvaller. Precies hier wordt bepaald of een inbraak een permanente achterdeur wordt.
Met PHP2Shell is dit scenario in oktober 2026 heel concreet geworden. De kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het mogelijk zonder aanmelding schadelijke code uit te voeren. Ze zijn sinds 21-10-2026 verholpen in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Goede bestandsrechten voorkomen geen aanval, maar ze voorkomen wel dat binnengebrachte code uw toepassing duurzaam herschrijft.
In veel installaties is alle code eigendom van de webservergebruiker, zodat updates met één druk op de knop werken. Dat is gemakkelijk, maar precies de constellatie die aanvallers zoeken.
Het grondprincipe: eigenaar en uitvoeringsgebruiker scheiden
Zinvol is een verdeling in twee rollen. Een eigenaar, bijvoorbeeld een deploy-gebruiker, bezit de bestanden en installeert updates. Het PHP-proces draait onder een andere gebruiker en heeft via de groep alleen leesrechten.
| Gebied | Eigenaar : groep | Rechten bestanden | Rechten mappen |
|---|---|---|---|
| Programmacode | deploy : seite1 | 640 | 750 |
| Configuratie met wachtwoorden | deploy : seite1 | 640 | – |
| Uploads, cache, tmp | seite1 : seite1 | 640 | 750 |
| Logs | root of seite1 | 640 | 750 |
De webserver zelf, bijvoorbeeld Nginx, heeft bij PHP-FPM alleen leestoegang nodig tot statische bestanden zoals afbeeldingen en CSS. Die krijgt u via de groep of een gerichte toegangsregel. Wie meerdere websites draait, geeft elk een eigen uitvoeringsgebruiker; hoe dat samenwerkt met pools, staat in de gids open_basedir en isolatie per website.
Bestandsrechten op de webserver controleren
Verschaf u eerst een overzicht voordat u iets wijzigt. De volgende opdrachten veranderen niets.
# Onder welke gebruiker draaien de PHP-processen?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Voor iedereen beschrijfbare bestanden en mappen
find /var/www -perm -o+w -ls
# Bestanden die eigendom zijn van de webservergebruiker (voorbeeld www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Rechten van de configuratiebestanden
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Voor iedereen beschrijfbare items zijn bijna altijd een fout. PHP-bestanden die eigendom zijn van de uitvoeringsgebruiker laten zien dat die zijn code kan wijzigen. Opvallend zijn bovendien afzonderlijke bestanden waarvan eigenaar of rechten afwijken van de naastliggende bestanden. Dat kan wijzen op binnengebrachte bestanden, zoals beschreven in de gids Webshells herkennen en verwijderen.
Rechten corrigeren: stap voor stap
Wijzig rechten alleen na een back-up en bij voorkeur eerst in een testomgeving. Bestaat het vermoeden van een inbraak, zet dan eerst de sporen veilig, want eigenaar en tijdstempels zijn dan bewijsmateriaal.
SITE=/var/www/seite1
# Eigenaar: deploy-gebruiker, groep: uitvoeringsgebruiker
sudo chown -R deploy:seite1 "$SITE"
# Mappen 750, bestanden 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Alleen deze mappen mag PHP beschrijven (paden aan de toepassing aanpassen)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Controleer daarna de website volledig: startpagina, login, formulieren, beeld-upload, caches. Welke mappen een toepassing moet kunnen beschrijven, staat in de systeemeisen van de fabrikant op diens officiële pagina.
Een chmod -R 777 om een probleem snel op te lossen, opent de server voor elke lokale gebruiker en elk binnengebracht proces. Corrigeer in plaats daarvan eigenaar en groep.
PHP-uitvoering in beschrijfbare mappen verhinderen
Schrijfrechten zijn maar half zo gevaarlijk als daar geen code kan draaien. Blokkeer de uitvoering van PHP in upload- en cachemappen op het niveau van de webserver. Voor Apache in de VirtualHost-configuratie:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Voor Nginx volstaat een location-blok dat verzoeken om PHP-bestanden in deze mappen afwijst. De regel hoort in de serverconfiguratie, niet in een .htaccess in de uploadmap, die een aanvaller met schrijfrechten weer zou kunnen wijzigen.
Aanvullend loont een blik op de umask van de deploy-gebruiker, zodat nieuwe bestanden niet automatisch te open worden aangemaakt. Een waarde van 027 leidt tot 640 voor bestanden en 750 voor mappen. Op eigen servers ligt deze verantwoordelijkheid volledig bij u; wat daar verder bij hoort, beschrijft Rootserver en vServer zelf beveiligen.
Bijzondere gevallen: hostingpanelen, shared hosting en deployments
Niet elke server laat zich volgens het leerboek inrichten. Hostingpanelen als Plesk of cPanel richten eigen gebruikers en rechten in en zetten die bij sommige acties terug. Wijzig rechten daar bij voorkeur via de functies van het paneel of controleer na paneelupdates of uw instellingen nog gelden.
Bij shared hosting hebt u meestal maar één gebruiker voor alles. Een scheiding van eigenaar en uitvoeringsgebruiker is dan niet mogelijk. Des te belangrijker zijn krappe rechten op configuratiebestanden, geen 777-rechten en het uitschakelen van PHP-uitvoering in uploadmappen, voor zover de hoster dat toestaat.
Wie met automatische deployments werkt, moet de rechten in het deploymentscript zelf instellen. Anders herstelt elke nieuwe versie de oude, te open toestand. Een korte controle aan het einde van de deployment, bijvoorbeeld met de opdracht voor beschrijfbare bestanden van hierboven, vangt zulke stappen terug betrouwbaar op en is zonder veel moeite in elke pipeline in te bouwen.
Hoe helpt PHP SOS concreet?
- We inventariseren eigenaar, rechten en uitvoeringsgebruiker van alle websites op de server.
- We stellen een rechtenconcept vast dat past bij uw toepassing en uw updateroute.
- We voeren rechten en uitvoeringsblokkades door en testen daarna de website volledig.
- We documenteren het concept, zodat deployments en updates het niet weer afzwakken.
Hoe dat in een duurzame beveiliging is ingebed, beschrijft de dienst Serververharding voor PHP-webservers.
Veelgestelde vragen
Zijn 777-rechten ooit in orde?
Op een productieserver vrijwel nooit. Met 777 mag elke gebruiker van het systeem bestanden aanmaken en wijzigen. Als een toepassing zonder 777 niet draait, is meestal de eigenaar verkeerd ingesteld, niet zijn de rechten te krap.
Waarom mag de webserver zijn eigen bestanden niet wijzigen?
Omdat binnengebrachte code met de rechten van de webserver draait. Mag de webserver PHP-bestanden schrijven, dan kan een aanvaller bestaande scripts manipuleren of nieuwe achterdeurtjes aanleggen. Scheidt u eigenaar en uitvoeringsgebruiker, dan blijft de code beschermd tegen schrijven.
Hoe werk ik een CMS bij als de webserver niet mag schrijven?
Updates lopen dan via de eigenaar, bijvoorbeeld met WP-CLI, Composer of deployment, niet via de updateknop in de backend. Dat is wat meer werk, maar binnengebrachte code kan zo geen programmabestanden wijzigen.
Welke rechten heeft het configuratiebestand met het databasewachtwoord nodig?
Zo weinig mogelijk: leesbaar voor de PHP-gebruiker, voor niemand anders. Gebruikelijk zijn 640 met passende groep of 400 als de PHP-gebruiker zelf eigenaar is.