WordPress is geweldig. Het is flexibel, gebruiksvriendelijk en drijft een groot deel van het internet aan. Maar die populariteit heeft een keerzijde: als er een kwetsbaarheid wordt gevonden, weten hackers dat direct. Is jouw website digitaal op slot gedraaid, of staat de achterdeur op een kier?
Bij SiteU zie ik regelmatig websites die gehackt zijn, puur omdat de basis niet op orde was. Vaak zijn het kleine, vergeten instellingen die grote gevolgen hebben. In dit artikel loop ik met je door de belangrijkste beveiligingspunten. Sommige kun je zelf direct oplossen, voor andere duiken we iets dieper de techniek in. Is het kwaad al geschied? Lees dan ook wat te doen als je site is gehackt.
1. Updates: saai maar noodzakelijk
Het klinkt als een open deur, maar het up-to-date houden van je WordPress 'core', plugins en thema's is de belangrijkste beveiligingsmaatregel. Zodra er een nieuwe versie van WordPress uitkomt om een lek te dichten, is de informatie over dat lek openbaar. Draai jij nog op een oude versie? Dan ben je een makkelijk doelwit.
- Core updates: zorg dat automatische updates voor kleine versies ('minor releases') aan staan. Deze bevatten vaak cruciale security patches.
- Plugins & thema's: check of plugins nog worden onderhouden door de maker. Is een plugin al langer dan 12 maanden niet bijgewerkt? Vervang hem dan door een veiliger alternatief. Oude code is kwetsbaar.
2. Verwijder digitale sporen
Je hoeft hackers niet te helpen. Standaard laat WordPress in de broncode van je site zien welke versie je gebruikt. Ook bestanden zoals readme.html, license.txt en wp-admin/install.php zijn na installatie nutteloos voor jou, maar goud waard voor hackers. Ze verklappen namelijk precies wat je draait.
Kwaadwillenden scannen het internet op deze bestanden. Verwijder ze uit je hoofdmap. Door deze informatie te wissen, maak je het verkenningswerk van een hacker een stuk lastiger.
3. De gebruikersnaam "admin"
Log jij in met de gebruikersnaam admin? Maak dan vandaag nog een nieuwe gebruiker aan met beheerdersrechten en verwijder het oude account.
Bij een 'brute-force' aanval probeert een script duizenden wachtwoorden uit. Als ze je gebruikersnaam al weten (omdat "admin" de standaard is), hebben ze het halve werk al gedaan. Gebruik ook nooit namen als "root", "test" of je eigen naam als inlognaam.
Een unieke gebruikersnaam is de eerste laag, maar niet voldoende. In stap 9 leg ik uit hoe je met passkeys of 2FA de volgende laag toevoegt, zodat zelfs een gelekt wachtwoord voor een hacker waardeloos wordt.
4. PHP en database versies
Je website draait op een server, en die server gebruikt software (PHP en MySQL). Oude versies van PHP (zoals 8.1 of lager) krijgen geen security updates meer en zijn onveilig. WordPress 7.0 (verwacht mei 2026) stelt PHP 7.4 als absolute minimum, maar in de praktijk is PHP 8.2 of 8.3 aanbevolen: sneller, en voor de komende jaren nog ondersteund door het PHP-team.
Controleer in je hostingpaneel op welke PHP-versie je zit. Is dit verouderd? Vraag je host om een update of schakel over. Let op: soms kan je site breken als je code te oud is voor nieuwe PHP-versies. In mijn PHP-reddingsoperatie lees je precies hoe ik zo'n migratie aanpak.
5. Verander de standaard database prefix
Nu duiken we even onder de motorkap. Standaard gebruikt WordPress wp_ als voorvoegsel voor alle tabellen in je database (bijvoorbeeld wp_users).
Als een hacker via een lek toegang krijgt tot je database, gokken ze vaak op deze standaard namen om data te stelen. Door dit te veranderen naar iets unieks (zoals x9s2_users), voeg je een sterke extra beveiligingslaag toe. Dit is een technische klus die je voorzichtig moet uitvoeren in de wp-config.php en de database zelf. Doe dit niet zonder backup.
wp-config.php vóór je aan deze migratie begint. Eén typfout in het tabel-prefix of één vergeten table-reference in wp_options en je site laadt niet meer. Kun je zo'n backup niet terugzetten? Dan ben je uren of dagen bezig voordat alles weer draait.
6. Zet "debug mode" uit
Tijdens het bouwen van een site is het handig om foutmeldingen te zien. Maar op een live website is WP_DEBUG of display_errors gevaarlijk.
Foutmeldingen geven namelijk vaak paden van bestanden of informatie over je database prijs aan bezoekers. Zorg dat foutmeldingen worden weggeschreven naar een afgeschermd logbestand en nooit zichtbaar zijn op het scherm.
7. Zet de code-editor op slot
Standaard kun je in WordPress via Weergave > Thema-bestand editor direct in de code van je website werken. Handig? Misschien. Gevaarlijk? Absoluut.
Als een hacker toegang krijgt tot je dashboard, kunnen ze via deze weg direct kwaadaardige code toevoegen of je site gijzelen. Schakel dit uit. Dit doe je door een simpele regel toe te voegen aan je wp-config.php bestand: define( 'DISALLOW_FILE_EDIT', true );.
8. Blokkeer XML-RPC
XML-RPC is een protocol uit de oertijd van het internet, bedoeld om op afstand met je site te communiceren (bijvoorbeeld via verouderde mobiele apps). Tegenwoordig gebruiken moderne tools de REST API, maar hackers zijn nog steeds dol op XML-RPC.
Ze gebruiken het namelijk massaal voor 'brute-force' aanvallen, waarbij ze honderden inlogpogingen tegelijk doen. Gebruik je geen externe apps? Zet deze poort dan dicht via een plugin of code.
Een regel in .htaccess of een plugin als 'Disable XML-RPC' doet het werk in een minuut. Check daarna of je normale inloggen nog werkt en of externe koppelingen (zoals Jetpack of een mobiele app) niet afhankelijk zijn van deze route. Bij veel shops scheelt dit direct merkbaar in bandbreedte en database-load, omdat het botverkeer op /xmlrpc.php vaak groter is dan je bezoekers vermoeden.
9. Passkeys en 2FA: einde aan het wachtwoord-tijdperk
Een sterk wachtwoord is al lang niet meer voldoende. Elke week staan er nieuwe wachtwoord-databases te koop op het dark web. Hergebruikt e-mailadres plus hetzelfde wachtwoord als op een andere site, en een hacker logt zo binnen. In 2026 zijn er twee beveiligingslagen die dit scenario feitelijk obsoleet maken, en beide zijn op een WordPress-site binnen tien minuten geregeld.
Passkeys vervangen het wachtwoord volledig. Je telefoon of hardware-key fungeert als inloggegevens: zonder dat fysieke apparaat kan niemand inloggen, ook niet met een gestolen wachtwoord. Sinds WordPress 6.8 zit er native ondersteuning ingebouwd, en met 6.9.1 is het productie-klaar. Inschakelen gaat via Gebruikers > Jouw profiel > Passkey beheren. Ik rol het standaard uit bij elke klant die ik onder handen neem.
Wil je passkeys nog niet, of draai je op een oudere WordPress-installatie? Two-factor authenticatie (2FA) is het absolute minimum. Plugins als Wordfence of de gratis "Two Factor" van WordPress.org voegen een tweede stap toe via een authenticator-app. Kies altijd voor TOTP (Time-based One-Time Password) boven SMS, want SMS-codes zijn te onderscheppen via SIM-swapping. Voor beheerders is 2FA in 2026 geen luxe meer: het hoort bij de basis, zoals een slot op je kantoordeur.
Eén praktische overweging die vaak vergeten wordt: als je meerdere beheerders of redacteuren hebt, geldt 2FA voor iederéén, niet alleen voor jou. Een website-redacteur met een zwak wachtwoord en geen tweede factor is een even groot risico als een beheerder. Zet 2FA verplicht op rol-niveau via een plugin als Wordfence of "Two Factor", en maak het een vaste onboarding-stap bij elke nieuwe medewerker. Dat is extra werk van een kwartier, maar je hoeft het maar één keer in te richten en daarna draait het automatisch mee.
10. MCP en de AI-laag: een nieuwe aanvalsoppervlakte
Dit punt staat nog niet op elke checklist, maar je komt er in 2026 steeds vaker mee in aanraking. WordPress 7.0 (verwacht mei 2026) bouwt een AI-infrastructuurlaag in de core: een Abilities API, een provider-neutrale AI Client, en een MCP Adapter waarmee externe assistenten als Claude en ChatGPT direct met je site kunnen praten. Zodra je AI-plugins installeert die deze laag gebruiken, ontstaat er een aanvalsoppervlakte die op oudere checklists simpelweg niet bestond.
Wat concreet misgaat: API-sleutels die in plain text in plugin-settings staan in plaats van in een environment-variabele. CVE-2025-6514 raakte vorig jaar duizenden MCP-servers precies om die reden. Overprivileged tokens die niet alleen lees- maar ook schrijfrechten hebben. MCP-endpoints zonder rate limiting. Plugin-configuraties die per ongeluk in een publieke Git-repo belanden. De mitigaties zijn bekend uit reguliere API-security: sleutels minimaal-privilege maken, ze regelmatig roteren, en ze opslaan op een plek waar de webserver ze wél kan lezen maar een crawler niet.
Voor het bredere verhaal over wat er in WordPress 7 verandert (Abilities API, MCP Adapter, AVG-verplichtingen en agentic commerce), schreef ik uitgebreid in WordPress 7 en AI: fundament, geen chatbot. Activeer je AI-plugins zonder deze fundamenten op orde? Dan bouw je de voordeur op slot maar laat je de kelderdeur wijd open.
11. Meten is weten: mijn favoriete tool
Klinkt dit als veel werk om handmatig te controleren? Dat is het ook. Gelukkig zijn er tools die je helpen de status van je site in kaart te brengen.
Een tool die ik zelf vaak gebruik voor een snelle scan is Security Ninja. Deze plugin voert meer dan 50 automatische checks uit, waaronder de punten die ik hierboven heb genoemd. Het geeft je direct een rapportcijfer: zie je veel rood? Dan is er werk aan de winkel. Zit je midden in een crisis? Begin dan eerst bij mijn eerste hulp bij website-nood.
