De thema- en plug-in-editor uitschakelen met DISALLOW_FILE_EDIT

Verborgen in elke standaard WordPress-installatie zijn twee pagina's die bijna niemand bewust gebruikt, maar die stilletjes een gestolen adminwachtwoord omzetten in een volledige servercompromittering. Weergave, Themabestandseditor en Plug-ins, Plug-in-bestandseditor. Beide laten een beheerder ruwe PHP-bestanden in de installatie rechtstreeks via de browser bewerken. Beide staan in 2026 nog steeds standaard aan. En beide zijn volledig optioneel.

Deze gids legt uit waarom het uitschakelen van de editors een van de hardeningwijzigingen met de hoogste hefboomwerking is die u op een WordPress-site kunt doen, hoe de enkele configuratieregel eruitziet, en wat u daarna kunt verwachten (inclusief een paar randgevallen die mensen verrassen).

Waarom is de ingebouwde code-editor een probleem?

Op een normale dag gebruikt niemand de editor. Themawijzigingen gaan via een childthema of de deploypipeline van een ontwikkelaar. Plug-inwijzigingen gebeuren op staging, niet in productie. De editor staat daar, ongebruikt, alleen toegankelijk voor beheerders.

"Alleen toegankelijk voor beheerders" is het deel dat onder aanval bezwijkt. De manier waarop de typische WordPress-overname zich afspeelt heeft niets te maken met code-niveau-kwetsbaarheden in de editor zelf. Het ziet er als volgt uit:

1. Een adminwachtwoord lekt uit. Phishing, hergebruik van wachtwoorden van een gehackte service, een ontwikkelaarslaptop met malware, een gecompromitteerde plug-in die sessiecookies exfiltreert. Kies een van de gebruikelijke ingangen.
2. De aanvaller logt in op /wp-admin als een echte adminbeheerder. Vanuit het perspectief van WordPress is er niets mis, dit is een legitieme login.
3. De aanvaller loopt rechtstreeks naar Weergave, Themabestandseditor, opent functions.php en plakt een kleine PHP-achterdeur bovenaan.
4. Vanaf dat moment voert elk verzoek aan de voorpagina van de site de code van de aanvaller uit. Ze hebben een externe shell op uw server.

De editor zet "gestolen adminwachtwoord" om in "gestolen webserver". Zonder de editor heeft een aanvaller die een adminwachtwoord steelt nog steeds adminrechten (wat al erg genoeg is), maar moet hij de tragere, luidruchtigere route nemen door een kwaadaardige plug-in- of themazip te uploaden om code-uitvoering te krijgen. Die extra stap is een extra kans voor een beveiligingsplug-in, een bestandsintegriteitsscanner of een WAF op serverniveau om de upload op te merken en te blokkeren.

De kosten-batenverhouding is enorm scheef. De editor wordt een paar keer per jaar gebruikt door een kleine minderheid van beheerders. Het risico komt naar voren bij elke site die een lek van inloggegevens krijgt. Het uitschakelen van de editor is een van die wijzigingen waarbij het slechtste geval is "iemand moet SFTP gebruiken voor een bewerking van vijf minuten" en het beste geval is "de overname escaleert nooit van een wachtwoordlek naar een achterdeur".

De oplossing: een enkele regel in wp-config.php

WordPress heeft een ingebouwde constante voor precies dit geval. Open wp-config.php in de WordPress-rootmap en voeg de volgende regel toe, ergens boven het commentaar dat luidt /* That's all, stop editing! Happy publishing. */:

define('DISALLOW_FILE_EDIT', true);

Sla het bestand op. Dat is alles. Het menu Themabestandseditor onder Weergave en de Plug-in-bestandseditor onder Plug-ins verdwijnen onmiddellijk voor elke gebruiker, inclusief beheerders. De pagina's zelf retourneren een rechtenfout als ze rechtstreeks via URL worden benaderd. Er is geen plug-in om te installeren, geen instelling om te onderhouden, geen compatibiliteitsoppervlak om u zorgen over te maken. De constante maakt sinds versie 3.0 (uitgebracht in 2010) deel uit van WordPress core en gaat nergens heen.

Wat als ik ook plug-in- en thema-uploads vanuit de admin wil blokkeren?

WordPress heeft een strenger zustertype constante genaamd DISALLOW_FILE_MODS. Het doet wat DISALLOW_FILE_EDIT doet, plus het blokkeren van plug-in-uploads, thema-uploads en core-updates vanuit de adminomgeving. Het instellen ziet er identiek uit:

define('DISALLOW_FILE_MODS', true);

Dat is een veel grotere gedragswijziging. Met DISALLOW_FILE_MODS actief kunt u geen plug-ins, thema's of WordPress core meer installeren of bijwerken via de normale adminomgeving. Alle updates moeten ergens anders vandaan komen: WP CLI, een deploypipeline, een SFTP-upload, of het centrale dashboard van een beheerde host.

Voor de meeste sites is dat te restrictief. Updates zijn de allerbelangrijkste beveiligingstaak op een WordPress-site, en ze moeilijker maken betekent meestal dat mensen ze overslaan. DISALLOW_FILE_MODS heeft zin in twee specifieke omgevingen: deploypipelines waar de productie-installatie alleen-lezen bedoeld is, en omgevingen met hoge beveiliging waar iemand werkelijk verantwoordelijk is voor het pushen van updates van buitenaf. Voor al het andere raakt de gewone DISALLOW_FILE_EDIT de sweet spot van "enorme beveiligingswinst, geen operationele pijn".

Wat verandert er voor gebruikers nadat u dit instelt?

Voor 99% van de beheerders op 99% van de sites: niets zichtbaars. De twee menu-items zijn weg uit het dashboard. Niemand merkt het op, omdat niemand ze gebruikte.

De gevallen waarin iemand het wel opmerkt:

• Een ontwikkelaar die productie rechtstreeks bewerkt. Als u iemand in het team hebt die routinematig thema- of plug-in-bestanden via de browser bewerkt, moet hij overschakelen naar SFTP of een deploypipeline. Dat is een werkstroomwijziging, geen blokkade. Sterker nog, dit is een goed moment om u af te vragen waarom productiecode überhaupt live wordt bewerkt.
• Plug-ins die haken in de editor. Een handvol plug-ins breidt de ingebouwde editor uit met extra functies. Ze zullen stilletjes hun UI niet laden wanneer de editor weg is. De plug-in zelf blijft meestal werken, alleen de editor-integratie breekt. Als u afhankelijk bent van een van deze, ziet u het gat tijdens het testen.
• Aangepaste code die edit_themes- of edit_plugins-rechten gebruikt. De constante verwijdert deze rechten van elke rol, inclusief beheerder. Code die functies afhankelijk maakt van precies deze rechten zal zich gedragen alsof niemand ze heeft. Zeldzaam, maar de moeite waard om te weten als u een aangepaste plug-in onderhoudt die dit type rechtencontrole uitvoert.

Verifiëren dat het actief is

1. Log in op WordPress als beheerder.
2. Open het menu Weergave in de adminzijbalk. Het item "Themabestandseditor" zou moeten ontbreken.
3. Open het menu Plug-ins. Het item "Plug-in-bestandseditor" zou moeten ontbreken.
4. Voor een extra controle navigeert u rechtstreeks naar https://uwdomein.nl/wp-admin/theme-editor.php. WordPress zou u moeten doorverwijzen naar een pagina die zegt "Sorry, u mag geen themabestanden bewerken".
5. Voer een nieuwe InspectWP-scan uit. De controle "bestandseditor ingeschakeld" in het beveiligingsgedeelte zou groen moeten worden.

Als de menu-items er nog steeds zijn nadat u wp-config.php hebt opgeslagen, zijn de meest voorkomende redenen: object cache (leeg deze), opcode cache zoals OPcache (het kan even duren voordat het nieuwe bestand wordt opgepikt, of u kunt PHP FPM herstarten), de bestandsbewerking is in een verkeerde wp-config.php in een bovenliggende map terechtgekomen, of de constante is later in het bestand door iets anders gezet en uw regel wordt overschreven. Open wp-config.php vanaf het allerbegin en zoek naar DISALLOW_FILE_EDIT; u zou uw regel moeten zien en niets anders dat deze daarna opnieuw instelt.

Wat deze oplossing wel en niet doet

Het is de moeite waard om duidelijk te zijn over welk type aanval DISALLOW_FILE_EDIT stopt en wat het onaangetast laat. Het stopt het specifieke pad waar een aanvaller een gestolen adminlogin gebruikt om PHP in thema- of plug-in-bestanden te schrijven via de browser. Het stopt niet:

• Een aanvaller die een kwaadaardige plug-in- of themazip uploadt vanuit de admin (gebruik daarvoor DISALLOW_FILE_MODS, met de hierboven beschreven afwegingen, of beperk de rechten voor plug-in-uploads).
• Een aanvaller die een code-niveau-kwetsbaarheid in een plug-in misbruikt om bestanden te schrijven. Daarvoor moet de plug-in zelf gepatcht worden.
• Een aanvaller die SFTP- of shell-toegang heeft. Op dat moment wordt de WordPress-laag volledig omzeild.

DISALLOW_FILE_EDIT is een verdedigingslaag, geen volledige strategie. Het past natuurlijk bij sterke adminwachtwoorden, tweefactorauthenticatie op adminaccounts, en een beveiligingsplug-in die let op onverwachte bestandswijzigingen. De combinatie verwijdert het gemakkelijkste overnamepad en maakt de moeilijkere paden luid genoeg om op te merken.

Eén regel in wp-config.php, geen plug-in, geen onderhoud, geen compatibiliteitsoppervlak. Als u deze maand niets anders doet aan een WordPress-site, doe dan dit.