Je leest dat WordPress-sites vaak gehackt worden, of je krijgt een melding van je hosting of van Wordfence, en je hebt geen idee waar je moet beginnen. WordPress-beveiliging rust op vijf lagen: actuele updates van core, thema’s en plugins, sterke wachtwoorden met tweestapsverificatie, een firewall, dagelijkse back-ups en monitoring op malware en inlogpogingen. Samen voorkomen ze het overgrote deel van de hacks die we in de praktijk tegenkomen. Hieronder loop ik per laag door wat je regelt, in welke volgorde je het aanpakt en wat je doet als het toch misgaat.
Waarom WordPress-sites worden aangevallen
WordPress-sites worden aangevallen omdat WordPress het meest gebruikte CMS ter wereld is, en dat maakt het voor aanvallers lonend om er automatisch naar zwakke plekken te zoeken. Dat zoeken doen bots, geen mensen. Ze lopen dag en nacht duizenden sites af op zoek naar een plugin met een bekend lek of een inlogscherm met een zwak wachtwoord. Het gaat dus zelden om jouw bedrijf persoonlijk, en dat werkt in je voordeel. Een bot zoekt de makkelijke prooi, dus wie de basis op orde heeft, valt al snel af. Klanten vragen me weleens of WordPress dan gewoon onveilig is. Mijn antwoord is altijd hetzelfde. WordPress zelf is niet onveilig, slecht onderhoud wel.
De meest voorkomende problemen met WordPress die tot een hack leiden, zijn verouderde plugins, zwakke of hergebruikte wachtwoorden en illegaal gekopieerde (nulled) thema’s waar al een achterdeur in zit. Wil je precies weten hoe elk van die ingangen werkt, lees dan de 7 oorzaken van een WordPress-hack.
De vijf lagen van WordPress-beveiliging
WordPress beveilig je het best als een huis, met meerdere lagen die elk iets anders opvangen. Een goed slot op de deur houdt de meeste inbrekers buiten, maar je wilt ook een alarm, een camera en een verzekering voor het geval het toch misgaat. Updates en sterke wachtwoorden zijn je sloten, de firewall is je alarm, monitoring is je camera en de back-up is je verzekering. Eén laag is nooit genoeg, want elke laag heeft een blinde vlek die de volgende afdekt. Die vijf lagen staan bovendien op een fundament, namelijk hosting die de server zelf beveiligt. Wat je daarvan mag verwachten, lees je verderop bij wie wat regelt.
Laag 1: updates van core, thema’s en plugins
Updates dichten bekende kwetsbaarheden, en de meeste kwetsbaarheden in WordPress zitten in plugins. Zodra een lek openbaar wordt (vaak met een CVE-nummer), staat het in databases als WPScan en Patchstack en gaan bots er gericht naar zoeken. Wachten met updaten is daarom het grootste risico dat ik zie. Mijn advies is om updates wekelijks na te lopen, bij een webshop eerst te testen op een staging-omgeving, en plugins en thema’s die je niet gebruikt helemaal te verwijderen in plaats van alleen uit te zetten. Een gedeactiveerde plugin staat nog steeds op je server en kan nog steeds misbruikt worden.
Ook je PHP-versie hoort bij deze laag. Kies een versie die op php.net nog beveiligingsupdates krijgt. Op onze shared hosting stel je zelf een versie tussen PHP 7.4 en 8.5 in via cPanel > Select PHP Version. Meer lezen? Zie WordPress veilig updaten, verouderde plugins opruimen, kwetsbaarheden in plugins monitoren, waarom je nooit nulled thema’s gebruikt en PHP-versie updaten.
Laag 2: wachtwoorden, tweestapsverificatie en gebruikersrollen
Toegangsbeveiliging zorgt dat alleen de juiste mensen op de juiste plek kunnen inloggen. Begin met een uniek wachtwoord per account uit een wachtwoordmanager, en zet tweestapsverificatie (2FA) aan voor iedereen met beheerdersrechten. Met 2FA heeft een aanvaller aan een gestolen wachtwoord alleen niet genoeg. Beperk daarnaast het aantal inlogpogingen, zodat een brute force-aanval (een bot die duizenden wachtwoorden achter elkaar probeert) vastloopt. Wat ik bij controles nog geregeld tegenkom, zijn accounts met de gebruikersnaam admin en oud-medewerkers die nog beheerder zijn. Geef de beheerdersrol alleen aan wie de site echt beheert.
Vergeet de toegang buiten WordPress niet. Je hostingpaneel verdient ook 2FA, en voor bestanden gebruik je SFTP in plaats van gewoon FTP. XML-RPC zet je uit als je het niet gebruikt. De REST API zet je niet helemaal uit, want de blokeditor heeft hem nodig, maar je kunt wel voorkomen dat gebruikersnamen via die API op straat liggen. En let op phishingmails die om je inloggegevens vragen, want die zijn soms nauwelijks van echt te onderscheiden. Verder lezen kan in je WordPress-login beveiligen, wachtwoordmanagers en veilige wachtwoorden en gebruikersrollen in WordPress.
Laag 3: firewall (WAF)
Een firewall (WAF) blokkeert schadelijk verkeer voordat het je website bereikt. Je kunt hem op drie niveaus inzetten, namelijk op de server, via een proxy zoals Cloudflare, of als plugin in WordPress. Het verschil zit in het moment waarop er gefilterd wordt. Een serverfirewall houdt een aanval tegen voordat WordPress laadt, terwijl een pluginfirewall pas ingrijpt als WordPress al draait en de aanval dus al serverkracht kost. Daarom vind ik dat een firewall op de server hoort, niet alleen in een plugin.
Beveiligingsplugins zoals Wordfence, Sucuri of Solid Security kunnen wel nuttig aanvullen. Ze zijn sterk in 2FA, het beperken van inlogpogingen en het controleren of bestanden zijn gewijzigd. DDoS-bescherming, het afvangen van een stortvloed aan verkeer, hoort daarentegen echt op server- of proxyniveau thuis. De afweging lees je in firewall op serverniveau of plugin.
Laag 4: back-ups als vangnet
Een back-up voorkomt geen hack, maar bepaalt hoe snel je weer online bent. Dat werkt alleen als de back-up automatisch en dagelijks wordt gemaakt, buiten je eigen server staat en meerdere dagen teruggaat. Een infectie kan al dagen in je site zitten voordat je hem opmerkt, en dan heb je niets aan alleen de back-up van gisteren. Test daarnaast af en toe of terugzetten echt werkt, liefst voordat je het nodig hebt.
Eén waarschuwing geef ik iedereen mee. Een back-up terugzetten zonder de oorzaak te dichten, betekent dat je binnen korte tijd opnieuw gehackt bent, want het lek zit er nog. Hoe je de frequentie kiest en hoe terugzetten werkt, lees je in hoe vaak je een back-up maakt en back-up terugzetten.
Laag 5: monitoring op malware en inlogpogingen
Monitoring zorgt dat je een hack binnen uren ziet in plaats van na weken. Hoe eerder je het merkt, hoe kleiner de schade en hoe kleiner de kans dat Google een waarschuwing bij je site zet. Dit zijn de signalen die ik in de gaten houd.
- Malwarescans van bestanden en database.
- Mislukte inlogpogingen en nieuwe beheerders die je niet kent.
- Gewijzigde core-bestanden.
- Een activiteitenlog die vastlegt wie plugins installeert of rollen wijzigt.
- Uptime, oftewel of je site bereikbaar is.
Onder al deze lagen ligt nog een basisvoorwaarde, namelijk HTTPS via een SSL-certificaat. Bij ons is dat gratis via Let’s Encrypt en wordt het automatisch verlengd zolang je DNS naar Surver wijst. Zie SSL-certificaat en HTTPS.
WordPress beveiligen: begin met deze zeven stappen
Twintig beveiligingstips afvinken is minder waard dan vijf lagen die echt werken. Begin met updates, tweestapsverificatie en een back-up die je kunt terugzetten, de rest is aanvulling. Heb je vandaag maar een uur, dan zou ik het in deze volgorde doen.
- Maak een back-up en voer daarna alle updates uit.
- Verwijder plugins en thema’s die je niet gebruikt.
- Zet tweestapsverificatie aan voor alle beheerders.
- Loop de beheerdersaccounts na, verwijder onbekende accounts en verlaag rollen die te ruim zijn.
- Controleer of er dagelijkse back-ups buiten de server staan en of terugzetten werkt.
- Ga na of je hosting een firewall en malwarescans heeft.
- Schakel bestandsbewerking in het dashboard uit met
define('DISALLOW_FILE_EDIT', true);inwp-config.php.
Ben je wat technischer, dan kun je daarna nog een stap verder gaan. Zet de bestandsrechten op 644 voor bestanden en 755 voor mappen, zodat niet iedereen op de server overal in kan schrijven. Blokkeer ook het uitvoeren van PHP in de map wp-content/uploads. Daar horen alleen afbeeldingen en documenten te staan, dus een PHP-bestand op die plek is bijna altijd verdacht.
Wat minder oplevert dan je denkt, is het verbergen van je WordPress-versie of het wijzigen van de databaseprefix. Het kan geen kwaad, maar bots proberen bekende lekken gewoon uit zonder eerst naar je versienummer te kijken. Ik zie liever dat je die tijd in de zeven stappen hierboven steekt.
Wie regelt wat: hosting, onderhoud of jij?
Hosting beveiligt de server, maar niet wat je zelf op je site installeert. Dat misverstand kom ik vaak tegen. Mensen gaan ervan uit dat de hostingpartij alles afdekt, terwijl een verouderde plugin of een gedeeld wachtwoord gewoon jouw kant van de streep is. Goede managed WordPress hosting regelt de serverkant, dus de firewall, malwarescans, de afscherming tussen accounts en de back-ups. De tabel laat zien hoe dat bij Surver is verdeeld.
| Laag | Surver hosting (alle shared pakketten) | WordPress onderhoud en beheer | Jij zelf |
|---|---|---|---|
| Updates | Serversoftware en PHP-patches | Maandelijkse updates van core, thema’s en plugins | Wat je installeert en of je updates uitvoert |
| Toegang | Captcha-pagina na meer dan tien mislukte inlogpogingen, 2FA op my.surver.nl en cPanel | Vanaf Business login protection met 2FA | Wachtwoorden, wie toegang heeft, welke rol |
| Firewall | ModSecurity-firewall, Bot Blocker, DDoS-bescherming | Vanaf Business een WAF op siteniveau | Eventueel een aanvullende plugin |
| Back-ups | Dagelijkse back-ups op aparte servers binnen Europa, terugzetten via JetBackup 5 | Bij Enterprise worden updates eerst op staging getest | Testen of terugzetten werkt |
| Monitoring | Imunify-malwarescans, isolatie met CloudLinux en CageFS | Uptimecheck elke minuut, vanaf Business een dagelijkse vulnerability scan en activity log | Onbekende beheerders en vreemde content opmerken |
Wat we bij Surver op elk shared hostingpakket standaard doen, is die serverkant zo dicht mogelijk zetten. Een ModSecurity-firewall en DDoS-bescherming houden het meeste schadelijke verkeer tegen voordat het je site raakt. Imunify scant bij elke bestandswijziging en zet een verdacht bestand meteen op slot, en na meer dan tien mislukte inlogpogingen, ook op wp-admin, krijgt het IP-adres een captcha-pagina. Als klant merk je daar meestal niets van, en dat is precies de bedoeling. Wat we niet voor je kunnen doen op alleen hosting, is je plugins bijwerken of bepalen wie er beheerder is. Wil je dat ook uit handen geven, dan valt dat onder WordPress beheer. Vanaf het Business-niveau zitten daar ook een WAF, een vulnerability scanner, login protection met 2FA en een activity log in. Op Surver Cloud werkt het iets anders, met een malwarescanner en site firewall en optioneel ModSecurity of Cloudflare.
Extra aandacht voor een WooCommerce-webshop
Een WooCommerce-webshop vraagt meer beveiliging dan een gewone site, omdat je persoonsgegevens bewaart zoals klantaccounts, adressen en bestellingen. Laat betalingen altijd via een betaalprovider zoals Mollie lopen, zodat kaartgegevens nooit op je eigen site terechtkomen. Geef iedereen die bij de bestellingen kan 2FA, ook de collega die alleen pakketjes verstuurt, en maak vaker een back-up dan bij een informatieve site. Elke bestelling is data die je niet kwijt wilt. Hoe je dat inricht, staat in WooCommerce beveiligen. Heb je liever dat iemand de updates en controles van je shop overneemt, kijk dan naar WooCommerce onderhoud.
Als het toch misgaat: herkennen, herstellen en melden
Een gehackte site herken je aan onbekende beheerders, doorverwijzingen naar spam, een waarschuwing van Google of je browser, of een melding van je hosting. Merk je zoiets, raak dan niet in paniek maar werk in vaste stappen. Wat je in het eerste uur doet, zoals wachtwoorden wijzigen en bewijs bewaren, lees je in WordPress-website gehackt, wat nu?.
Daarna komt het opschonen, en daar gaat het vaak mis. Een back-up terugzetten is niet genoeg, want aanvallers laten achterdeurtjes (backdoors) achter die ook in je back-ups kunnen zitten. Hoe je die opspoort, beschrijf ik in malware verwijderen uit WordPress. Is dat je te technisch, dan kun je het opschonen en dichten van de oorzaak laten doen via WordPress gehackt.
Staat er een rode waarschuwing bij je site in Google, dan vraag je na het opschonen een beoordeling aan in Search Console. Hoe dat gaat, lees je in de Google-waarschuwing verwijderen. Zijn er mogelijk persoonsgegevens ingezien, dan heb je bovendien een wettelijke plicht. Je meldt het datalek binnen 72 uur bij de Autoriteit Persoonsgegevens, en soms moet je ook de betrokkenen inlichten. Meer daarover in meldplicht bij een datalek.
Beveiliging en de AVG
De AVG verplicht je om passende technische maatregelen te nemen om persoonsgegevens te beschermen, en de vijf lagen uit deze gids vormen daar de kern van. Daarnaast verwacht de wet een paar dingen die buiten de techniek van je site liggen. Je gebruikt HTTPS, je hebt een verwerkersovereenkomst met je hostingpartij en je cookiebanner vraagt echte toestemming. Die verwerkersovereenkomst is bij ons standaard, ook voor e-mailhosting, en staat op surver.nl/juridisch/verwerkersovereenkomst/. De cookiebanner kun je zelf regelen of als cookie-module laten inrichten. Wij gebruiken daarvoor Complianz en stellen hem in op basis van een paar vragen over je site.
Wil je weten waar je verder op moet letten, lees dan wat de AVG technisch vraagt, welke cookiebanner verplicht is en Cookiebot zonder plugin implementeren. Dit is praktische uitleg, geen juridisch advies.
Beveiliging is onderhoud, geen eenmalige klus
De vijf lagen zet je één keer goed neer, maar ze blijven alleen werken als je ze bijhoudt. Een plugin die vandaag veilig is, kan volgende maand een bekend lek hebben, en een back-up die je nooit test, is een gok. Mijn advies: neem elke maand je updates, je beheerders en een testherstel van je back-up mee. Hoe je dat ritme opzet, staat in de onderhoudschecklist.
Veelgestelde vragen
Is WordPress veilig?
Ja, de WordPress-core is goed beveiligd en krijgt snel updates als er een lek wordt gevonden. Het risico zit bijna altijd in verouderde plugins, zwakke wachtwoorden en achterstallig onderhoud. Met de vijf lagen uit deze gids dek je die zwakke plekken af.
Heb ik een beveiligingsplugin nodig?
Niet per se. Draait je site bij Surver op shared hosting, dan zitten een ModSecurity-firewall en malwarescans met Imunify al op de server. Een plugin is dan een aanvulling, vooral handig voor 2FA en het beperken van inlogpogingen.
Moet ik de inlog-URL van WordPress veranderen?
Het mag, en het scheelt botverkeer op /wp-login.php, maar het is geen beveiliging op zich. Tweestapsverificatie en een limiet op inlogpogingen doen het echte werk.
Hoe vaak moet ik WordPress updaten?
Beveiligingsupdates voer je zo snel mogelijk uit, zeker als het lek al actief wordt misbruikt. Overige updates doe je minstens één keer per maand, altijd na een verse back-up.
