WordPress beveiligen: 10 maatregelen op volgorde van effect

WordPress beveiligen begint niet bij een plugin, maar bij updates. Daarna volgen tweestapsverificatie, zo min mogelijk plugins en back-ups die buiten je server staan. Een beveiligingsplugin, goede hosting, een recente PHP-versie, een afgeschermde inlogpagina, strakke rechten en monitoring maken het af. Die volgorde volgt uit waar de lekken zitten.

De kern is goed onderhouden. Patchstack telde over 2025 in totaal 11.334 nieuwe kwetsbaarheden in het WordPress-ecosysteem, 42 procent meer dan een jaar eerder. Daarvan zat 91 procent in plugins en 9 procent in thema's. In WordPress zelf werden er zes gevonden, allemaal met lage prioriteit.

Twee andere cijfers uit hetzelfde rapport bepalen de volgorde hieronder. Bij 46 procent van de lekken was er nog geen update beschikbaar op het moment dat het lek openbaar werd. En bij de lekken die het meest werden misbruikt, was de gewogen mediane tijd tot massaal misbruik vijf uur na bekendmaking.

Een WordPress-site veilig houden gaat dus vooral over wat je eraan hangt en hoe snel je bijwerkt. Is het al misgegaan, lees dan eerst WordPress gehackt: dat is een stappenplan voor herstel, dit artikel gaat over voorkomen.

De volgorde is onze weging, want goede WordPress beveiliging is vooral een kwestie van prioriteren: hoeveel risico een maatregel wegneemt, gedeeld door de tijd die hij kost. De eerste vier doe je in een middag en dekken het grootste deel van de lekken waar al een update voor is. Tegen de lekken zonder update helpt vooral stap 3: minder plugins, dus minder wat open kan staan.

1. WordPress updates van core, thema en plugins

Kleine updates van WordPress zelf gaan sinds versie 3.7 automatisch, en sites die sinds versie 5.6 zijn aangemaakt krijgen ook de grote versies automatisch. Plugins en thema's niet: die zet je sinds WordPress 5.5 per stuk aan in het scherm Plugins of onder Weergave. WordPress draait die automatische updates standaard twee keer per dag en stuurt een mail als er een is gelukt of mislukt.

Dat laatste is de reden om WordPress plugin updates niet blind automatisch te laten lopen op een site die omzet draait. Een update kan een andere plugin of je thema breken. Wat werkt: kleine, veelgebruikte plugins automatisch, grote en betaalde plugins eerst op een testomgeving (staging) en daarna live. En altijd met een recente back-up, zoals WordPress.org zelf ook aanraadt voor elke update.

Met vijf uur tussen bekendmaking en massaal misbruik is wekelijks bijwerken te traag voor de plugins die het meest worden aangevallen.

2. Tweestapsverificatie en sterke wachtwoorden

Een lang, uniek wachtwoord uit een wachtwoordmanager, en een tweede stap bij het inloggen. WordPress heeft tweestapsverificatie niet ingebouwd; je voegt het toe met een plugin. De handleiding van WordPress.org noemt daarvoor Two-Factor, en Wordfence heeft het ook, zie stap 5. Zet het in elk geval aan voor elke beheerder.

Gebruik daarnaast geen account met de naam admin. Dat is de eerste gebruikersnaam die een aanvaller probeert.

3. Minder plugins

Elke plugin is code van iemand anders die op je server draait, en dus een ingang. Loop de lijst na: wat is uitgeschakeld, wat is vervangen, wat doet iets wat het thema al kan? Uitgeschakeld is niet genoeg. De bestanden staan dan nog op de server, dus verwijder wat je niet gebruikt. Download plugins alleen van WordPress.org of rechtstreeks van de maker.

4. Back-ups buiten je server

Een back-up op dezelfde server als de site verdwijnt mee als die server wordt gewist, besmet of afgesloten. Zorg dat er minstens één kopie ergens anders staat, en dat je hebt geprobeerd hem terug te zetten. Hoe je dat inricht staat in WordPress back-up.

5. Wordfence of een andere beveiligingsplugin

Wordfence is de bekendste, met meer dan vijf miljoen actieve installaties. De gratis versie heeft een firewall, een scanner voor malware, tweestapsverificatie en beveiliging van het inloggen. Eén beperking staat op de pluginpagina zelf: de regels van de firewall en de kenmerken voor de malwarescan komen in de gratis versie dertig dagen later binnen dan in Premium.

Wat een beveiligingsplugin niet oplost: een plugin met een bekend lek die je niet bijwerkt, een wachtwoord dat elders is uitgelekt, of een aanval die al binnen is voordat de plugin draaide. Het is een extra laag bovenop stap 1 tot en met 4, geen vervanging. Kies er één, en loop de instellingen na in plaats van alles op standaard te laten staan.

6. Hosting

Op gedeelde hosting deel je een server met andere sites, en een besmetting kan verder reiken dan jouw account. Vraag je host of elke site een eigen database en een eigen gebruiker krijgt, zoals WordPress.org aanraadt, en welke firewall er voor de site staat.

Reken daar niet te veel op. Patchstack liet in twee onderzoeken aanvallen los op beveiligde hostingomgevingen: in het eerste werd 12 procent van de aanvallen op bekende lekken tegengehouden, in het tweede 26 procent. De firewall van je host is een aanvulling, geen reden om updates uit te stellen.

7. PHP-versie

WordPress.org raadt PHP 8.3 of hoger aan. PHP 8.2 krijgt van de makers van PHP nog tot eind 2026 beveiligingsupdates, 8.1 en ouder niet meer. Je host laat je de versie meestal zelf kiezen in het beheerpaneel. Test een overstap eerst op staging, want een oude plugin kan op een nieuwe PHP-versie stoppen.

8. Inlogpagina en admin-URL

De inlogpagina is een vast doelwit van geautomatiseerde inlogpogingen, in de handleiding van WordPress.org brute force genoemd. Beperk het aantal pogingen, bij voorkeur al bij de firewall of de webserver, zodat het verkeer je site niet eens bereikt. Een andere admin-URL scheelt ruis in je logboeken, maar WordPress.org noemt het expliciet geen verdediging op zichzelf. Gebruik je XML-RPC niet, bijvoorbeeld voor de app of een koppeling, zet het dan uit.

9. Rechten

Twee soorten. Gebruikersrollen: geef redacteuren de rol Redacteur en geen beheerdersrechten, en ruim accounts op van mensen die er niet meer werken. Bestandsrechten: wp-config.php op 400 of 440, en /wp-content/ beschrijfbaar voor de webserver. Maak je de rest alleen-lezen, dan kan WordPress zichzelf niet meer bijwerken en vraagt hij bij elke update om FTP-gegevens. Dat botst met de automatische updates uit stap 1, dus kies bewust: strakke rechten en zelf bijwerken, of automatische updates. Zet daarnaast deze regel in wp-config.php, zodat niemand via het dashboard code van plugins of thema's kan aanpassen:

define( 'DISALLOW_FILE_EDIT', true );

10. Monitoring

Je wilt het weten voordat een klant het meldt. Meld je site aan bij Google Search Console, zodat je een melding krijgt als Google een beveiligingsprobleem vindt. Laat de scan van je beveiligingsplugin mailen bij wijzigingen in bestanden, en houd bij wie wanneer inlogt. WordPress.org noemt logboeken en het bewaken van bestanden als de manier om een inbraak vroeg te zien.

Zelf doen kan prima. De eerste vier stappen kosten een middag om in te richten en daarna vooral discipline: elke week kijken wat er bij te werken is, en na elke update even door de site klikken. Het wordt lastiger als de site omzet draait en een update op vrijdagmiddag dus niet kan wachten tot maandag, of als niemand in het team het als zijn taak ziet.

Een eenvoudige toets: weet je binnen een dag dat een plugin een kritieke update heeft gekregen, en wie hem installeert? Zo nee, dan is dat het gat. Een tweede toets: staat er ergens op papier wie de back-ups controleert, wie de beheerdersaccounts bijhoudt en wie er gebeld wordt als Search Console een melding stuurt? Staat daar niemand, dan is uitbesteden het overwegen waard. Wat WordPress beveiliging en onderhoud per maand kost, en waar het verschil in zit, staat bij de kosten van WordPress onderhoud.

We bouwen tegenwoordig vooral maatwerk in Next.js en Payload, maar onderhouden ook WordPress-sites. Wil je het niet zelf doen, dan kunnen we het onderhoud, de monitoring en de updates overnemen. Hoe je de beveiliging ook inricht: begin bij stap 1, want daar zit het grootste deel van het risico.

• State of WordPress Security in 2026, Patchstack, opgehaald op 29 september 2026
• Hardening WordPress, WordPress Advanced Administration Handbook, opgehaald op 29 september 2026
• Multi-factor authentication, WordPress Advanced Administration Handbook, opgehaald op 29 september 2026
• Brute Force Attacks, WordPress Advanced Administration Handbook, opgehaald op 29 september 2026
• Upgrading WordPress, WordPress Advanced Administration Handbook, opgehaald op 29 september 2026
• Plugin and themes auto-updates, WordPress.org Documentation, opgehaald op 29 september 2026
• Requirements, WordPress.org, opgehaald op 29 september 2026
• Wordfence Security, WordPress.org Plugins, opgehaald op 29 september 2026