WordPress beveiligen — 10 stappen
Het volledige stappenplan als je dit zelf wil doorlopen: van updates en 2FA tot WAF-configuratie en .htaccess hardening. Uitgelegd zonder vakjargon, ook als je geen technische achtergrond hebt.
De meeste gehackte WordPress-sites die bij mij binnenkomen hadden één ding gemeen: een gat dat ze hadden kunnen dichten. Een contactformulier-plugin met een bekende kwetsbaarheid die al maanden openstond. PHP in de uploads-map die nooit was afgesloten. Een admin-account met een wachtwoord van voor 2018. Ik doe de audit, voer de hardening uit die bij jouw situatie past, en zet monitoring in — zodat je bij een volgend incident een melding krijgt in plaats van een e-mail van je hoster.
Dit zijn de zes dingen die ik bij bijna elke gehackte WordPress-site zie. Soms één, soms drie tegelijk. Ze zijn bijna altijd van tevoren te voorkomen geweest.
Veruit het meest gezien. Plugin-release-notes beschrijven precies welk lek is gedicht — bots lezen diezelfde notes en scannen daarna gericht op sites die nog niet hebben geüpdatet. De patch staat beschikbaar, maar je moet hem ook installeren.
Brute-force aanvallen op wp-login.php en xmlrpc.php draaien 24/7. Een zwak of hergebruikt wachtwoord geeft in minuten toegang. Zonder 2FA is een gestolen wachtwoord voldoende voor volledige admin-controle.
De wp-content/uploads/ map hoort alleen afbeeldingen te bevatten, maar draait standaard PHP. Aanvallers uploaden een webshell via een kwetsbaar formulier-plugin en hebben daarmee volledige server-toegang — ook nadat je alles hebt “opgeschoond”.
Ik zie regelmatig sites waarbij de hack al maanden actief was voordat iemand het merkte. Intussen draait het domein als spam-relay of casino-linkfarm, en bouwt Google-vertrouwen af. File-integrity monitoring stuurt een melding zodra er iets wijzigt — niet pas als een klant er melding van maakt.
xmlrpc.php staat standaard aan in WordPress en biedt aanvallers een alternatieve ingang die brute-force-bescherming op de login-pagina omzeilt. Via de system.multicall-methode kunnen duizenden wachtwoorden per request worden getest. Eén regel in .htaccess sluit dit af.
Elk extra admin-account is een extra aanvalsdoelwit. Voormalige medewerkers, web-bureaus die ooit toegang hadden, test-accounts van installaties — ze zijn er allemaal nog. Aanvallers gaan voor de accounts met het meest voor de hand liggende wachtwoord. Minst actieve accounts, meest kwetsbaar.
Dit is wat ik doorloop. Niet alles is voor elke site even relevant — dat bepaalt de audit. Maar het zijn maatregelen die ik op bijna elke site tegenkom die ze nog niet heeft.
DISALLOW_FILE_EDIT uit, DISALLOW_FILE_MODS overwegen, database-prefix aanpassen als dat nog wp_ is, secret keys roteren. Bestandsrechten op 640 of 600 zetten zodat de webserver het kan lezen maar niet schrijven.
.htaccess in wp-content/uploads/ die .php, .phtml en .php5 bestanden weigert. Dit breekt 80% van alle geautomatiseerde webshell-aanvallen. Eén bestand, enorme impact. Standaard zit dit er niet in.
xmlrpc.php volledig via .htaccess. Gebruik je het wél, dan beperk ik het tot de specifieke IP-adressen die het nodig hebben.
admin-gebruikersnaam hernoemen als die nog bestaat.
wp_options op geïnjecteerde JavaScript of redirect-code (vaak in widgetinstellingen of siteurl), check wp_users op accounts die direct in de database zijn aangemaakt, en wp_posts op hidden iframes of base64-blobs. Leftover-tabellen van verwijderde plugins worden ook opgeruimd — ze zijn geen aanvalsvector op zichzelf maar reduceren de footprint.
wp-config.php, readme.html, license.txt, .git-mappen en de logs-map. Directorylijsting uitschakelen. HTTP-headers voor security toevoegen: X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
wp-login.php beperken tot jouw IP-adres via .htaccess — de effectiefste maatregel die er is als je altijd vanaf een vast IP werkt.
ALL PRIVILEGES. Dat is te veel. Ik maak een gebruiker aan met alleen de rechten die WordPress nodig heeft: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER. Zo kan een aanvaller via SQL injection minder schade aanrichten.
Je weet na afloop wat er was, wat er is gedaan en waarom. Geen rapport van twintig pagina's — gewoon een helder overzicht zodat je het zelf kunt bijhouden.
Ik doorloop de volledige site: plugin-versies, bestandsrechten, .htaccess-configuratie, database-setup, actieve admin-accounts, log-bestanden. Ik gebruik zowel handmatige inspectie als geautomatiseerde tools om niks te missen. De audit is altijd kosteloos.
Je krijgt een concreet overzicht van wat ik heb gevonden: welke kwetsbaarheden, hoe ernstig, en in welke volgorde ze moeten worden opgelost. Inclusief een eerlijke tijdschatting. Pas als je akkoord gaat, begin ik met de hardening.
Alle maatregelen doorvoeren op jouw specifieke situatie: plugins, hosting-configuratie, databaseversie, of je al een security-plugin hebt. Geen generieke template — ik pas elke maatregel aan op wat jouw site nodig heeft en wat de hoster toestaat.
Na de hardening stel ik monitoring in en lever ik documentatie: wat is er gedaan, wat zijn de nieuwe inloggegevens, hoe werkt 2FA, wat te doen bij een alarm. Je bent volledig op de hoogte en kunt daarna zelf bijhouden of onderhoud uitvoeren.
Wil je de techniek erachter begrijpen of zelf iets doorlopen?
Het volledige stappenplan als je dit zelf wil doorlopen: van updates en 2FA tot WAF-configuratie en .htaccess hardening. Uitgelegd zonder vakjargon, ook als je geen technische achtergrond hebt.
Hoe je wp-login.php en xmlrpc.php beschermt tegen geautomatiseerde inlogpogingen, alleen met .htaccess en server-configuratie. Werkt ook als Wordfence te zwaar is voor je hosting.
Het meest gevoelige bestand in je WordPress-installatie. Hoe je het beschermt met bestandsrechten, .htaccess-regels en de juiste constanten in wp-config.php zelf.
Drie DNS-records die spoofing voorkomen — waarbij aanvallers mail sturen vanaf jouw domeinnaam zonder je site te hacken. Standaard onderdeel van mijn hardening.
Beveiligen en opruimen zijn niet hetzelfde. Als er al iets actief is, moet dat eerst weg — daarna pas hardening. Herken je één van deze drie?
Search Console heeft mogelijk al een Manual Action. Bezoekers haken massaal af bij dit label. De melding verdwijnt niet door de site te beveiligen — er is eerst een volledige cleanup en herindexering nodig. Zie mijn hack-opruim pagina voor het volledige stappenplan.
Cloaking-hacks waarbij Googlebot andere content krijgt dan jij. Je site ziet er normaal uit, maar in zoekresultaten staat spam. Volledig ander type aanpak nodig: detectie, forensische backup, cleanup, dan hardening. Casino-spam, Japanse spam, pharma-hack — elk met eigen artikel.
Mail van TransIP, Hostnet of Antagonist over "verdachte uitgaande mail"? Je hebt een deadline van 24-48 uur. Beveiligen alleen helpt hier niet — de bron moet gestopt worden. Lees het stappenplan of bel direct.
De audit is altijd gratis. Voor de hardening geldt: hoe groter de installatie, hoe meer werk. Standaard WordPress-site met een handvol plugins: 2-3 uur. Grotere sites met custom code of meerdere beheerders: 4-6 uur. Na de audit weet je het exact, vóór ik begin.
Wat de prijs bepaalt:
Wat er het vaakst gevraagd wordt.
Hangt af van de site. Een standaard WordPress-installatie met een handvol plugins doe ik in 2-4 uur. Grotere sites of sites met veel custom code langer. De audit om dat te bepalen is altijd kosteloos — daarna weet je wat het kost voor we beginnen.
Een volledige hardening-sessie duurt 2-4 uur, afhankelijk van de staat van de site. Tijdens de hardening is de site gewoon bereikbaar — ik werk in de achtergrond en geef vooraf aan welke stappen een korte downtime vereisen. Na afloop lever ik een overzicht van wat er is gedaan en waarom.
Ja. Een security-plugin detecteert problemen — dat is niet hetzelfde als voorkomen dat ze kunnen binnenkomen. Wordfence of Sucuri horen gewoon in de setup, maar ze vervangen de hardening niet. De plugin is je alarm; de hardening is je slot.
Zeker. Een eerdere hack betekent niet dat de site structureel onveilig is — het betekent dat er op dat moment een ongedicht gat was. Na hardening sluit ik alle bekende aanvalsvectoren. Als er ook nog kans bestaat dat eerdere malware of backdoors aanwezig zijn, doe ik eerst een volledige cleanup en dan de hardening. Ik check dit tijdens de gratis audit.
Een security-plugin detecteert en blokkeert bekende aanvallen. Hardening verandert de structuur van je site zodat aanvallen minder kans hebben om te landen. Voorbeeld: een plugin blokkeert mislukte login-pogingen; hardening verplaatst de aanvalsvector, beperkt toegang op IP-niveau, en zet 2FA aan. Een plugin zonder hardening is een alarm zonder slot.
De hardening zelf hoef je maar één keer te doen. Wat daarna aandacht vraagt: plugins opschonen als je iets niet meer gebruikt, wachtwoorden roteren en updates bijhouden. Als je dat liever uitbesteedt kan ik jaarlijks een check doen.
Ja. Brute-force bescherming op wp-login.php en xmlrpc.php is standaard onderdeel van de hardening — rate limiting, IP-blokkades en 2FA maken geautomatiseerde aanvallen vrijwel kansloos. Voor DDoS-mitigation (volumetrische aanvallen) heb je een cloud-WAF nodig zoals Cloudflare, die ik ook kan instellen en configureren.
Managed hosting (WP Engine, Kinsta) beheert al bepaalde lagen: server-configuratie, automatic updates, basic firewalling. Maar WordPress-niveau hardening — 2FA, wp-config beveiligen, plugin-audit, uploads-map vergrendelen, file-integrity monitoring — is altijd jouw verantwoordelijkheid. Ik ken de beperkingen van de grote managed platforms en weet wat er nog handmatig gedaan moet worden.
Ja. Ik werk regelmatig op shared hosting van TransIP, Antagonist, Hostnet, Yourhosting en One.com. Elke hoster heeft zijn eigen beperkingen — op sommige kun je .htaccess-regels niet volledig controleren, andere blokkeren bepaalde PHP-functies. Ik weet wat er per hoster wel en niet kan en pas de hardening daarop aan. Niet elke maatregel is overal mogelijk, maar de meest impactvolle zijn dat altijd.
Bijna volledig. De meeste hardening-stappen hebben geen enkel effect op de beschikbaarheid van de site. De enige stap die kort offline kan zijn: als ik de database-gebruiker wissel of de database-prefix aanpas, is de site voor 1-2 minuten niet bereikbaar. Ik doe dat altijd buiten de drukste uren en geef vooraf aan wanneer het gepland is. Alles erna draait gewoon door.
HTTPS versleutelt het verkeer tussen bezoeker en server — het zegt niks over de veiligheid van de WordPress-installatie zelf. De meeste hacks die ik zie lopen via plugins, wachtwoorden of serverbestanden. Een SSL-certificaat is voorwaarde voor een betrouwbare site, maar het is geen beveiliging van WordPress. Dat zijn twee verschillende lagen.
Audit is altijd kosteloos. Stuur een bericht via WhatsApp of mail — ik reageer op werkdagen binnen 4 uur en bij noodgevallen vaak binnen het uur.
Website Technical Support Specialist
WordPress · Drupal · Joomla · OpenCart · CMS Made Simple
Spoed? Bel altijd — bij echte noodgevallen reageer ik vaak binnen 30 minuten.