Uw website bestaat uit een paar duizend bestanden op een server. Elk van die bestanden heeft een klein etiket waarop staat wie het mag lezen, wie het mag wijzigen en wie het mag uitvoeren. Zolang die etiketten kloppen, merkt u er niets van. Kloppen ze niet, dan krijgt u óf foutmeldingen bij updates en uploads, óf een aanvaller krijgt vrij spel om bestanden te wijzigen. Het eerste is vervelend, het tweede is gevaarlijk.

De bestandsrechten van WordPress zijn dus geen detail voor techneuten, maar een basisinstelling die u minstens één keer wilt controleren. Zeker als uw site ooit is verhuisd, als een vorig bureau “iets heeft opengezet om een probleem op te lossen” of als een beveiligingsscan een waarschuwing geeft. In dit artikel leggen wij uit wat de cijfers betekenen, welke waarden juist zijn en hoe u ze stap voor stap controleert.

Wat die cijfers betekenen

Op een Linux-server, en dat is vrijwel altijd waar WordPress op draait, kent elk bestand drie soorten gebruikers: de eigenaar, de groep en de rest van de wereld. Voor elk van die drie is vastgelegd of ze mogen lezen (4), schrijven (2) en uitvoeren (1). De cijfers worden opgeteld. Een bestand met rechten 644 betekent: de eigenaar mag lezen en schrijven (6), de groep mag alleen lezen (4), en iedereen anders mag alleen lezen (4).

Voor mappen betekent “uitvoeren” dat u de map mag openen. Daarom hebben mappen bijna altijd een extra 1 ten opzichte van bestanden: 755 in plaats van 644.

De waarde die u nooit wilt zien, is 777. Die betekent dat iedereen alles mag, ook schrijven. Op een server waar meerdere websites draaien, kan dan in het ergste geval een besmette buursite uw bestanden overschrijven. Het wordt vaak ingesteld als snelle “oplossing” wanneer een upload of update niet lukt, en daarna vergeten.

De juiste bestandsrechten voor WordPress

De standaardwaarden die WordPress zelf aanbeveelt, en die op vrijwel elke hosting goed werken:

  • Alle mappen: 755. Inclusief wp-content, wp-content/uploads en wp-content/plugins.
  • Alle bestanden: 644. Thema- en pluginbestanden, afbeeldingen, alles.
  • wp-config.php: 600 of 640. Dit bestand bevat uw databasewachtwoord en beveiligingssleutels. Strenger is beter, zolang de webserver het nog kan lezen. Werkt 600 niet op uw hosting, probeer dan 640 en anders 644.
  • .htaccess: 644. Sommige beheerders kiezen 604 zodat de groep het niet kan lezen; dat is een detail.

Minstens zo belangrijk als de cijfers is de eigenaar. De bestanden moeten eigendom zijn van de gebruiker waaronder de webserver (of PHP) draait, anders kan WordPress zelf geen updates uitvoeren en geen bestanden uploaden. Dat is precies de situatie waarin mensen 777 gaan instellen. De juiste oplossing is dan niet de rechten verruimen, maar de eigenaar corrigeren; dat kan alleen uw hostingpartij of iemand met servertoegang.

Stappenplan: controleren en corrigeren

  1. Maak een back-up. Ook al verandert u alleen rechten en geen inhoud. Een verkeerde massawijziging kan uw site tijdelijk onbereikbaar maken.
  2. Open uw site via FTP of de bestandsbeheerder van uw hostingpaneel. Programma’s als FileZilla tonen de rechten in een kolom, vaak als cijfer of als reeks letters (rwxr-xr-x is hetzelfde als 755).
  3. Zoek naar afwijkingen. Kijk vooral in wp-content en in de hoofdmap. Ziet u 777, 666 of 775 op plekken waar dat niet hoort, noteer dan welke.
  4. Corrigeer per categorie. In de meeste FTP-programma’s kunt u met de rechtermuisknop op een map klikken en de rechten aanpassen, inclusief onderliggende bestanden. Doe mappen en bestanden apart: mappen naar 755, bestanden naar 644. Sommige hostingpanelen hebben hiervoor een knop “bestandsrechten herstellen”, wat veiliger is dan handwerk.
  5. Zet wp-config.php apart op 600 of 640 en test daarna of de site nog laadt. Zo niet, ga een stap terug naar 644.
  6. Test de site. Laad de homepage, log in, upload een testafbeelding en controleer of een plugin-update lukt. Werkt alles, dan is het klaar.

Wie servertoegang heeft, doet dit sneller met twee opdrachten via SSH: één die alle mappen op 755 zet en één die alle bestanden op 644 zet. Weet u niet wat SSH is, laat dit dan aan uw hostingpartij over.

Een voorbeeld: de webshop die niet meer kon updaten

Een kleine webshop in kinderkleding uit Breda kreeg bij elke plugin-update de melding dat WordPress geen bestanden kon schrijven. Een eerdere beheerder had dat “opgelost” door de map wp-content op 777 te zetten. De updates werkten weer, maar een beveiligingsscan meldde maandenlang een kritieke waarschuwing die niemand begreep.

De echte oorzaak was dat de bestanden bij een verhuizing eigendom waren geworden van de FTP-gebruiker in plaats van de webservergebruiker. Nadat de hostingpartij de eigenaar had gecorrigeerd, konden alle rechten terug naar 755 en 644, werkten updates gewoon, en verdween de waarschuwing. Zonder de oorzaak te kennen, was 777 de enige manier geweest om het werkend te houden; daarom is dit typisch een probleem om samen met de hosting op te lossen.

Wat bestandsrechten wel en niet beschermen

Goede bestandsrechten voorkomen dat de rest van de server, of een andere website op dezelfde machine, uw bestanden kan wijzigen. Ze voorkomen niet dat een aanvaller die via een lek in een plugin binnenkomt, bestanden schrijft: die aanvaller handelt dan namelijk als de webserver zelf, en die mag schrijven. Bestandsrechten zijn daarmee één laag in een stapel: ze horen naast een firewall, tijdige updates en een controle op gewijzigde kernbestanden. Hoe u die laatste controle doet, leest u in ons artikel over kernbestanden controleren op wijzigingen.

Als u deze controle liever niet zelf doet, hoort het nalopen van bestandsrechten en eigenaarschap thuis in een eerste beveiligingsbeurt. Bij WebMaintor is dit onderdeel van de inrichting van beveiliging voor uw website; ook een goede hostingpartij kan het voor u nalopen. Een extra maatregel die wij daarbij altijd meenemen, is het uitschakelen van de bestandseditor in het WordPress-beheer, zodat thema- en pluginbestanden niet via de browser te bewerken zijn.

Conclusie

Mappen op 755, bestanden op 644, wp-config.php strenger, en nooit 777. Controleer het één keer grondig, zeker na een verhuizing of na een wisseling van bureau. Lukt een update daarna niet, verruim dan niet de rechten, maar laat de eigenaar van de bestanden corrigeren. Dat is de enige oplossing die het probleem echt wegneemt. Wilt u begrijpen hoe aanvallers de bestanden gebruiken die ze wél kunnen schrijven, lees dan verder over backdoors in WordPress.