Elke WordPress-website heeft een bestand dat wp-config.php heet. Daarin staan de gebruikersnaam en het wachtwoord waarmee je website bij zijn database komt, en in die database zitten al je pagina’s, je berichten en je gebruikers. Wie dat bestand kan lezen, heeft de sleutel tot je database in handen.
Daaromheen zitten drie instellingen die bepalen hoeveel een buitenstaander over je website te weten komt, en wat iemand kan doen die ooit in je dashboard terechtkomt. Staat de foutopsporing aan, ook wel de debugmodus genoemd? Is de bestandsbewerker in je dashboard beschikbaar? En laten je mappen zien wat erin staat? Wat je prijsgeeft, kan iemand gericht gebruiken. Hoe minder er te zien is, hoe minder er te richten valt.
Een beveiligingscontrole van je WordPress-website kijkt naar precies deze vier. Twee zet je zelf goed met één regel in wp-config.php, de andere twee regelt de server. Download vooraf een kopie van wp-config.php naar je eigen computer. Een typefout in dat bestand haalt je hele website offline, en met die kopie ben je in een minuut weer terug.
Alle vier de punten op een rij
| Wat je nakijkt | Zo kijk je het zelf na | Dit hoor je te zien | Hier los je het op |
|---|---|---|---|
| wp-config.php van buitenaf te lezen | Je domein met /wp-config.php erachter | Een lege pagina of een foutmelding | Server |
| Foutopsporing (debugmodus) | De regel met WP_DEBUG in wp-config.php | define( 'WP_DEBUG', false ); | wp-config.php |
| Bestandsbewerker | Tools bij een blokthema, Weergave en Plugins bij een klassiek thema | Geen bewerker in het menu | wp-config.php |
| Mappen die tonen wat erin staat | Je domein met /wp-content/uploads/ erachter | Een foutmelding of een lege pagina, geen lijst met bestanden | Server |
Je databasewachtwoord uit het zicht houden
Of iemand met de gegevens uit wp-config.php ook echt in je database komt, hangt af van je hosting, maar die gok wil je niet nemen.
Een goed ingestelde server voert dit bestand uit en toont het aan niemand. Staat de server verkeerd ingesteld, dan krijgt een bezoeker die het adres opvraagt alles als gewone tekst te zien. Dat gebeurt ook met een reservekopie zoals wp-config.php.bak naast het origineel, want een bestand dat niet op .php eindigt, voert de server meestal niet uit maar geeft hij gewoon mee, als tekst in je browser of als download.
Zo zie je of wp-config.php te lezen is
Typ je eigen domein in de adresbalk met /wp-config.php erachter. Je hoort een lege pagina of een foutmelding te krijgen. Zie je tekst die begint met <?php of regels waarin DB_PASSWORD voorkomt, dan ligt je databasewachtwoord op straat en is dat het eerste wat je laat repareren.
Afschermen gebeurt in de serverinstellingen van je hosting. Bij een Apache-server is dat meestal het .htaccess-bestand, bij een NGINX-server de serverconfiguratie. Dat verschilt per hosting, dus vraag je hostingpartij ernaar of laat het nakijken.
Twee instellingen die je zelf regelt in wp-config.php
De volgende twee zet je zelf goed, elk met één regel in wp-config.php. Heb je nog geen kopie van het bestand op je eigen computer, maak die dan nu eerst.
Foutmeldingen van je live website af houden
WordPress kan technische foutmeldingen op je pagina’s tonen. Dat is handig tijdens het bouwen, maar op een live website ziet een bezoeker een blok onleesbare tekst over je pagina. En in die meldingen staan paden op de server en soms de naam van je database, precies de informatie waarmee iemand gericht verder zoekt.
In een nieuwe WordPress staat de foutopsporing uit. Staat hij bij jou aan, dan is hij tijdens het bouwen aangezet en daarna blijven staan.
Zoek de regel met WP_DEBUG en zet hem op false. Staat hij er niet, dan voeg je hem toe boven de regel die zegt dat je klaar bent met bewerken.
define( 'WP_DEBUG', false );Dit is de juiste stand voor een live website. Regels met WP_DEBUG_DISPLAY of WP_DEBUG_LOG eronder doen dan niets meer. Of PHP, de programmeertaal waarin WordPress draait, zelf nog meldingen toont, bepaalt de serverinstelling display_errors, en die hoort live uit te staan. Twijfel je, vraag het je hostingpartij.
Zoeken jij of je bouwer een fout, zet de foutopsporing dan tijdelijk aan met de meldingen in een logbestand in plaats van op het scherm.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/pad/buiten/je/website/wp-errors.log' );Geef bij de laatste regel een pad op buiten de publieke map van je website. Zet je daar alleen true, dan komt het logbestand als debug.log in wp-content, en dat kan iedereen opvragen tenzij de server het tegenhoudt. Gevonden wat je zocht? Zet dan de ene regel van hierboven terug en ruim het logbestand op.
De bestandsbewerker uit je dashboard halen
In je dashboard zit een bewerker waarmee je de programmacode van je thema en je plugins rechtstreeks aanpast, en die staat in elke nieuwe WordPress aan. Gebruik je een blokthema, zoals de standaardthema’s van WordPress sinds Twenty Twenty-Two, dan vind je hem onder Tools. Bij een klassiek thema staat hij onder Weergave en onder Plugins.
Iedereen met beheerdersrechten kan daar code veranderen. Geeft een wijziging een fatale fout op je homepage of in je dashboard, dan zet WordPress de oude code terug. Een fout die alleen op een andere pagina optreedt, of iets wat net niet crasht, blijft staan, zonder eerdere versie om op terug te vallen. En komt iemand ooit bij een beheerdersaccount, dan is dit vaak het eerste wat die probeert.
Eén regel haalt hem weg.
define( 'DISALLOW_FILE_EDIT', true );De bewerker voor je thema en die voor je plugins verdwijnen allebei, ook voor wie het adres rechtstreeks intypt. Plugins installeren en bijwerken blijft werken, dus een beheerder kan nog altijd een plugin uploaden. Deze regel haalt de kortste route weg om code aan te passen, niet elke route. Bij een blokthema blijft onder Weergave het item Editor staan. Daarmee ontwerp je pagina’s, met code heeft dat niets te maken.
Echte aanpassingen aan je thema doe je in een childthema, een eigen laag bovenop je thema, of via je bouwer, met een back-up ernaast. Werken er meer mensen in je dashboard, geef dan iedereen een eigen account in plaats van een gedeelde login.
Je mappen dicht voor wie rondkijkt
Vraagt iemand een map van je website op waar geen eigen startbestand in staat, zoals de map met je uploads, dan tonen sommige servers gewoon de lijst met wat erin zit. Daarmee ziet iemand al je bestanden, ook de bestanden die nergens op een pagina staan. Aan de mappen die plugins er zelf aanmaken is vaak te zien welke plugins je gebruikt.
Typ je domein met /wp-content/uploads/ erachter. Zie je een lijst met jaartallen en bestandsnamen, dan staat de map open. Krijg je een foutmelding of een lege pagina, dan is het goed geregeld.
Het werkt hetzelfde als een versienummer dat uitlekt. Wie weet welke plugin je draait, kan opzoeken of daar een zwakke plek van bekend is en die gericht proberen. Dichtzetten doet de server, met één instelling die het tonen van die lijst uitzet.
Wat deze vier je opleveren
Na deze vier is er van buitenaf een stuk minder te zien over hoe je website in elkaar zit, en is de kortste route om code aan te passen dicht. Onneembaar wordt je website er niet van, dat belooft niemand eerlijk, maar je valt wel af bij de geautomatiseerde zoektochten naar een makkelijk doelwit.
Wat openstaat, zegt niet dat er iemand binnen is geweest. Het laat zien welke deur je nog dicht kunt doen.
Wil je nog minder prijsgeven, scherm dan ook je gebruikersnamen af.
En gebruik je geen app of koppeling die het nodig heeft, zet XML-RPC dan uit.
De twee regels in wp-config.php zet je zelf goed. De twee serverinstellingen zien er op elke hosting anders uit. Op de Premium WordPress-hosting staan de serverinstellingen al goed voor je, en ze blijven goed staan als je WordPress of een plugin bijwerkt.
Wat er verder bij een goed beveiligde website hoort, vind je in alle beveiligingsmaatregelen op een rij.
Kom je er bij de serverinstellingen niet uit, laat het me dan even weten.
Veelgestelde vragen
Nee. Een open punt zegt dat er een deur openstaat, niet dat er iemand binnen is geweest. Dat controleer je los hiervan, en twee dingen zeggen het meeste. Kijk in je dashboard onder Gebruikers of er accounts tussen staan die je niet herkent, en kijk of WordPress, je plugins en je thema's allemaal bijgewerkt zijn. Vind je daar niets geks, dan is er ook geen aanleiding om aan te nemen dat er iets gebeurd is.
Nee, je website blijft doen wat hij deed. Je merkt er twee dingen van. De bestandsbewerker verdwijnt uit je dashboard, dus die route om code aan te passen is weg. En WordPress zet zelf geen foutmeldingen meer op je pagina's. Een enkele plugin kijkt of je in het dashboard bestanden mag bewerken en gebruikt dat ook voor iets anders. Doet er na deze wijziging een plugin vreemd, dan weet je waar je moet kijken.
Deels. Veel beveiligingsplugins hebben een schakelaar voor de bestandsbewerker, en sommige waarschuwen als de foutopsporing aanstaat of schermen het logbestand af. Voor de twee serverinstellingen schrijven sommige plugins regels in het .htaccess-bestand. Dat werkt alleen op een Apache-server, en het blijft afhankelijk van een plugin die actief moet blijven. Het verschil zit hem erin of iets in de server staat of in een plugin die iemand ooit kan uitzetten.
Meestal in de hoofdmap van je website, op dezelfde plek als de mappen wp-content en wp-admin. Zie je hem daar niet, kijk dan één map hoger, want daar zoekt WordPress ook. Je komt erbij met FTP of met de bestandsbeheerder in je hostingpaneel. Download eerst een kopie naar je eigen computer voordat je iets verandert, en laat geen reservekopie op de server staan.
Naast je databasegegevens staan er de beveiligingssleutels waarmee WordPress je inlogcookies ondertekent, zodat niemand zelf een geldig inlogcookie kan maken. En de tabelprefix die bepaalt hoe je databasetabellen heten. Daar verander je niets aan, want na de installatie laat een andere prefix WordPress denken dat het nog niet geïnstalleerd is. Juist door die sleutels en gegevens hoort dit bestand privé te blijven.