WordPress beveiligen is in 2026 geen kwestie van één securityplugin installeren en vervolgens aannemen dat je website veilig is.

Een WordPress-website bestaat uit meerdere lagen: de hostingomgeving, PHP, WordPress zelf, plugins, thema's, gebruikersaccounts, de database, bestanden, externe koppelingen en natuurlijk de apparaten waarmee beheerders inloggen.

Een zwakke plek in één van deze onderdelen kan voldoende zijn om een website kwetsbaar te maken.

Daarom kijken we in deze WordPress Security Checklist voor 2026 naar de volledige beveiliging van een WordPress-website.

Van updates en tweefactorauthenticatie tot backups, bestandsrechten, HTTPS, Application Passwords en monitoring.

Het doel is niet om een WordPress-installatie theoretisch "onhackbaar" te maken — dat bestaat niet.

Het doel is om:

• de kans op een succesvolle aanval sterk te verkleinen;
• onnodige aanvalsmogelijkheden te verwijderen;
• verdachte activiteiten sneller te ontdekken;
• schade bij een incident te beperken;
• en de website snel te kunnen herstellen als er toch iets misgaat.

Waarom WordPress-beveiliging in 2026 belangrijk blijft

WordPress is enorm flexibel.

Je kunt een eenvoudige bedrijfswebsite bouwen, maar ook een webshop, ledenplatform, leeromgeving, boekingssysteem of compleet maatwerkplatform.

Die flexibiliteit betekent tegelijkertijd dat een WordPress-installatie vaak uit software van verschillende leveranciers bestaat.

Je hebt bijvoorbeeld:

WordPress Core
De basissoftware van WordPress.

Plugins
Aanvullende functionaliteit van WordPress.org, commerciële leveranciers of maatwerkontwikkelaars.

Thema's
De presentatie en soms ook een aanzienlijk deel van de functionaliteit.

Hosting
De webserver, PHP, database, opslag en netwerklaag.

Externe diensten
Bijvoorbeeld betalingsproviders, CRM-systemen, nieuwsbrieftools, analytics, API's en automatiseringen.

Een beveiligingsprobleem hoeft dus niet noodzakelijk in WordPress Core te zitten.

Een kwetsbare plugin, gestolen administrator-login, verkeerd ingestelde server of gelekt API-wachtwoord kan eveneens toegang geven tot een website.

WordPress zelf benadrukt daarom dat beveiliging uit verschillende lagen bestaat en onder andere afhankelijk is van serverbeveiliging, wachtwoorden, bestandsrechten, databasebeveiliging, plugins, backups, logging en monitoring.

WordPress Security Checklist 2026

Wil je eerst een snelle controle uitvoeren? Begin dan met deze punten:

• WordPress Core is bijgewerkt

• Alle plugins zijn bijgewerkt

• Het actieve thema is bijgewerkt

• Ongebruikte plugins zijn verwijderd

• Ongebruikte thema's zijn verwijderd

• PHP draait op een actuele, ondersteunde versie

• Alle beheerders gebruiken unieke wachtwoorden

• 2FA is ingeschakeld voor beheerders

• Oude gebruikersaccounts zijn verwijderd

• Gebruikers hebben alleen de rechten die ze nodig hebben

• De volledige website draait via HTTPS

• Automatische backups zijn ingesteld

• Backups worden buiten dezelfde hostingomgeving bewaard

• Backups worden daadwerkelijk getest

• Bestandsrechten zijn correct ingesteld

• wp-config.php is voldoende beschermd

• File editing vanuit wp-admin is indien passend uitgeschakeld

• Application Passwords worden gecontroleerd

• Ongebruikte Application Passwords zijn ingetrokken

• Loginpogingen en verdachte activiteiten worden gemonitord

• Er is malware- of integriteitsmonitoring

• WordPress Site Health wordt regelmatig gecontroleerd

• Beheerders weten wat ze moeten doen bij een beveiligingsincident

Heb je op meerdere punten "nee" geantwoord? Dan is er werk aan de winkel.

Hieronder behandelen we ieder onderdeel uitgebreid.

1. Houd WordPress Core altijd bijgewerkt

De eerste stap is eenvoudig:

gebruik een actuele WordPress-versie.

Updates bevatten niet alleen nieuwe functionaliteit en bugfixes. Ze kunnen ook beveiligingsproblemen oplossen.

Een website maanden of zelfs jaren op een oude WordPress-versie laten draaien vergroot daarom onnodig het risico.

Ga regelmatig naar:

Dashboard → Updates

en controleer welke updates beschikbaar zijn.

Automatische WordPress-updates

WordPress ondersteunt automatische updates voor verschillende onderdelen.

Dat is vooral nuttig voor beveiligings- en onderhoudsupdates.

Maar automatische updates betekenen niet dat je nooit meer naar je website hoeft te kijken.

Een update kan bijvoorbeeld een compatibiliteitsprobleem veroorzaken met:

• een plugin;
• je thema;
• maatwerkcode;
• WooCommerce;
• een externe koppeling.

Een professionele updateprocedure bestaat daarom uit meer dan alleen op Update klikken.

Idealiter heb je:

1. een recente backup;
2. monitoring;
3. een stagingomgeving voor grotere wijzigingen;
4. en een controle na de update.

Test na belangrijke updates bijvoorbeeld:

• formulieren;
• login;
• navigatie;
• zoekfunctie;
• WooCommerce-winkelwagen;
• checkout;
• betalingen;
• e-mail;
• API-koppelingen.

2. Update plugins zo snel mogelijk

Voor veel WordPress-sites zijn plugins één van de belangrijkste onderdelen van het securityoppervlak.

Dat is logisch.

Een WordPress-website kan tientallen plugins bevatten, allemaal met hun eigen code, functies, gebruikersrechten, databasequeries en soms externe verbindingen.

Wanneer een beveiligingslek in een plugin wordt ontdekt en een update beschikbaar komt, wil je die update niet maanden laten liggen.

Controleer daarom regelmatig:

Plugins → Geïnstalleerde plugins

Let daarbij niet alleen op beschikbare updates.

Controleer ook of plugins nog actief worden onderhouden.

Een plugin zonder updates is niet automatisch onveilig

Een eenvoudige plugin kan lange tijd geen nieuwe versie nodig hebben.

Maar wees extra voorzichtig wanneer:

• de plugin al jaren niet meer is bijgewerkt;
• er compatibiliteitsproblemen zijn;
• de ontwikkelaar verdwenen lijkt;
• bekende beveiligingsproblemen niet worden opgelost;
• de plugin niet meer noodzakelijk is.

In dat geval is het verstandig een alternatief te onderzoeken.

3. Verwijder plugins die je niet gebruikt

Een gedeactiveerde plugin levert normaal gesproken geen actieve functionaliteit aan je website.

Maar de bestanden staan nog steeds op de server.

Daarom is het beter om plugins die je definitief niet meer gebruikt volledig te verwijderen.

Vraag bij iedere plugin:

Hebben we deze nog nodig?

Zo niet:

verwijderen.

Dat heeft nog een bijkomend voordeel.

Minder plugins betekent meestal:

• minder onderhoud;
• minder updates;
• minder potentiële kwetsbaarheden;
• minder conflicten;
• en een eenvoudiger WordPress-installatie.

Security en eenvoud gaan vaak goed samen.

4. Verwijder ongebruikte thema's

Hetzelfde principe geldt voor WordPress-thema's.

Je hebt normaal gesproken niet acht verschillende thema's nodig.

Bewaar het actieve thema en eventueel een noodzakelijke parent theme wanneer je een child theme gebruikt.

Een recent standaard WordPress-thema als fallback kan in bepaalde situaties ook handig zijn.

Oude commerciële thema's die je al jaren niet meer gebruikt?

Verwijder ze.

Ook ongebruikte software moet namelijk onderhouden worden zolang deze op de server aanwezig blijft.

5. Gebruik een ondersteunde PHP-versie

WordPress draait grotendeels op PHP.

Een oude PHP-versie is daarom niet alleen een performanceprobleem, maar kan ook een beveiligingsprobleem worden wanneer die PHP-release geen beveiligingsupdates meer ontvangt.

Controleer via je hostingomgeving welke PHP-versie je gebruikt.

Je kunt informatie over je omgeving ook terugvinden via:

Gereedschap → Sitediagnose → Informatie

Update PHP niet blind op een productieomgeving.

Controleer eerst of:

• WordPress;
• je thema;
• plugins;
• en maatwerkcode

compatibel zijn met de nieuwe versie.

Maak vooraf een backup en test grotere PHP-upgrades bij voorkeur via staging.

6. Gebruik sterke en unieke wachtwoorden

Welkom123! is geen goed administratorwachtwoord.

Maar alleen een paar symbolen toevoegen maakt een voorspelbaar wachtwoord ook niet automatisch veilig.

Een goed wachtwoord moet vooral:

• lang;
• uniek;
• niet hergebruikt;
• en moeilijk te raden

zijn.

Het belangrijkste woord hier is uniek.

Gebruik niet hetzelfde wachtwoord voor:

• WordPress;
• hosting;
• e-mail;
• FTP/SFTP;
• databasebeheer;
• domeinregistratie;
• Cloudflare;
• andere zakelijke diensten.

Wanneer één dienst wordt gehackt en hetzelfde wachtwoord elders wordt gebruikt, kan een aanvaller proberen dezelfde gegevens op andere platforms te gebruiken.

Dit wordt vaak credential stuffing genoemd.

Gebruik een password manager

Voor beheerders is een password manager sterk aan te raden.

Daarmee hoef je wachtwoorden niet zelf te onthouden en kun je voor iedere dienst een lang, willekeurig en uniek wachtwoord gebruiken.

7. Activeer tweefactorauthenticatie

Een sterk wachtwoord is belangrijk.

Maar voor accounts met veel rechten is alleen een wachtwoord eigenlijk niet genoeg.

Gebruik daarom two-factor authentication (2FA) of een vergelijkbare extra authenticatielaag voor minimaal:

• administrators;
• webshopbeheerders;
• developers;
• hostingaccounts;
• domeinregistratie;
• DNS/CDN-accounts;
• zakelijke e-mailaccounts.

Bij 2FA is naast het wachtwoord nog een tweede factor nodig.

Afhankelijk van het systeem kan dat bijvoorbeeld een authenticatorapp of fysieke security key zijn.

Hierdoor is een gestolen wachtwoord alleen niet direct voldoende om in te loggen.

Geef voorkeur aan sterke MFA-methoden

Niet iedere tweede factor biedt hetzelfde beveiligingsniveau.

Waar beschikbaar verdienen phishing-resistente methoden zoals security keys en moderne passkey/WebAuthn-oplossingen de voorkeur voor zeer belangrijke accounts.

Voor veel WordPress-sites is een authenticatorapp met tijdgebonden codes echter al een enorme verbetering ten opzichte van alleen een wachtwoord.

8. Gebruik niet overal het account "admin"

Een WordPress-gebruikersnaam is geen geheim.

Alleen het veranderen van admin naar iets anders is daarom geen sterke beveiligingsmaatregel op zichzelf.

Toch is het verstandig geen voorspelbare generieke beheeraccounts te delen.

Maak liever persoonlijke accounts aan.

Dus niet:

admin

voor vijf medewerkers.

Maar bijvoorbeeld een afzonderlijk account voor iedere beheerder.

Waarom?

Omdat je dan kunt zien:

• wie een wijziging heeft gedaan;
• welk account heeft ingelogd;
• welk account moet worden ingetrokken wanneer iemand vertrekt.

Accountability is onderdeel van goede beveiliging.

9. Deel geen administratoraccounts

Dit sluit aan op het vorige punt.

Iedere beheerder hoort zijn eigen account te hebben.

Stel dat drie medewerkers hetzelfde administratoraccount gebruiken en je ziet om 03:15 uur 's nachts een verdachte wijziging.

Wie gebruikte het account?

Dat is moeilijk te bepalen.

Met persoonlijke accounts kun je veel beter:

• loggen;
• monitoren;
• rechten intrekken;
• 2FA beheren;
• incidenten onderzoeken.

10. Geef gebruikers zo weinig mogelijk rechten

Niet iedere WordPress-gebruiker hoeft Administrator te zijn.

WordPress heeft verschillende rollen, waaronder:

• Administrator;
• Editor;
• Author;
• Contributor;
• Subscriber.

WooCommerce en plugins kunnen daar aanvullende rollen aan toevoegen.

Gebruik het principe van least privilege:

Geef een gebruiker alleen de rechten die noodzakelijk zijn voor zijn of haar werkzaamheden.

Iemand die alleen blogartikelen schrijft hoeft bijvoorbeeld normaal gesproken geen plugins te kunnen installeren.

Een externe tekstschrijver hoeft geen toegang tot WooCommerce-instellingen te hebben.

Een marketingmedewerker hoeft mogelijk geen thema's te kunnen wijzigen.

Minder rechten betekent minder potentiële schade wanneer een account wordt overgenomen.

11. Controleer regelmatig alle WordPress-gebruikers

Ga naar:

Gebruikers → Alle gebruikers

en controleer wie toegang heeft.

Let vooral op:

• onbekende administrators;
• oude medewerkers;
• voormalige developers;
• oude bureaus;
• testaccounts;
• accounts die niemand meer gebruikt.

Verwijder accounts die niet meer nodig zijn of verlaag hun rechten.

Doe dit niet alleen wanneer iemand vertrekt.

Maak er bijvoorbeeld een periodieke securitycontrole van.

12. Beveilig niet alleen WordPress, maar ook je e-mailaccount

Dit wordt vaak vergeten.

Stel dat je WordPress uitstekend hebt beveiligd, maar een aanvaller krijgt toegang tot het e-mailadres van een administrator.

Die aanvaller kan mogelijk:

• password resets aanvragen;
• securitymeldingen onderscheppen;
• toegang krijgen tot andere diensten;
• zich voordoen als de eigenaar.

Je zakelijke e-mailaccount is daarom onderdeel van je WordPress-securitymodel.

Gebruik daar eveneens:

• een uniek wachtwoord;
• 2FA;
• actuele recoverygegevens;
• loginmonitoring.

13. Beveilig je hostingaccount

Een WordPress-securityplugin kan weinig doen wanneer een aanvaller rechtstreeks toegang krijgt tot je hostingaccount.

Vanuit hostingbeheer kan iemand mogelijk:

• bestanden wijzigen;
• databases openen;
• backups downloaden;
• DNS wijzigen;
• e-mailaccounts beheren;
• wachtwoorden resetten.

Bescherm je hostingaccount daarom minstens zo goed als WordPress zelf.

Gebruik:

• een uniek wachtwoord;
• 2FA wanneer beschikbaar;
• persoonlijke gebruikersaccounts wanneer het platform dat ondersteunt;
• en beperk toegang tot mensen die deze werkelijk nodig hebben.

14. Beveilig je domeinnaam en DNS

Wie controle heeft over je domeinnaam of DNS, kan verkeer mogelijk naar andere servers sturen.

WordPress zelf hoeft daarvoor niet eens gehackt te worden.

Bescherm daarom ook je:

• registraraccount;
• DNS-provider;
• CDN-account.

Gebruik opnieuw unieke wachtwoorden en 2FA.

Controleer daarnaast of contactgegevens en recoverymethoden bij je domeinprovider nog actueel zijn.

15. Gebruik overal HTTPS

Een moderne WordPress-website hoort volledig via HTTPS bereikbaar te zijn.

Niet alleen de checkout.

Niet alleen /wp-admin/.

De hele website.

HTTPS versleutelt het verkeer tussen browser en server.

Zonder TLS kunnen gegevens op onveilige netwerken makkelijker worden onderschept of aangepast.

Controleer daarom:

http://jouwdomein.nl

en zorg dat bezoekers automatisch worden doorgestuurd naar:

https://jouwdomein.nl

Controleer ook op mixed content.

Dat ontstaat wanneer een HTTPS-pagina bijvoorbeeld nog afbeeldingen, scripts of stylesheets via HTTP probeert te laden.

16. Zorg voor automatische backups

Backups voorkomen geen hack.

Maar ze bepalen wel hoe goed je kunt herstellen.

Stel dat:

• malware bestanden heeft aangepast;
• een aanvaller gebruikers heeft toegevoegd;
• gegevens zijn verwijderd;
• ransomware of sabotage plaatsvindt;
• een update de website beschadigt.

Dan wil je kunnen teruggaan naar een bekende, schone situatie.

Maak daarom automatisch backups van minimaal:

Database

en

websitebestanden.

Voor WooCommerce en andere dynamische websites kan een hogere backupfrequentie noodzakelijk zijn dan voor een eenvoudige bedrijfswebsite die maar één keer per maand verandert.

17. Bewaar niet al je backups op dezelfde server

Een backup op dezelfde server is beter dan helemaal geen backup.

Maar het is geen ideale strategie.

Wanneer de server volledig wordt beschadigd, verwijderd of gecompromitteerd, kan de backup eveneens verloren gaan.

Gebruik daarom bij voorkeur een tweede locatie.

Bijvoorbeeld:

• externe object storage;
• gespecialiseerde backupdienst;
• aparte backupserver;
• andere fysiek of logisch gescheiden opslag.

Het belangrijkste principe is:

één incident mag niet tegelijkertijd de website én alle bruikbare backups vernietigen.

18. Test je backups

"We maken iedere nacht backups."

Mooi.

Maar kun je ze ook terugzetten?

Een backup waarvan nooit is getest of hij bruikbaar is, is geen volledig herstelplan.

Test periodiek:

• of de database aanwezig is;
• of alle bestanden aanwezig zijn;
• of de backup niet corrupt is;
• of je een restore kunt uitvoeren;
• hoeveel tijd een herstel kost.

Bij kritieke websites hoort restore-testing bij normaal beheer.

19. Bepaal hoe lang backups worden bewaard

Alleen "dagelijkse backup" zegt niet genoeg.

Stel dat malware 20 dagen geleden is geïnstalleerd en je hebt alleen backups van de laatste zeven dagen.

Dan bevatten al je beschikbare backups mogelijk dezelfde besmetting.

Denk daarom na over retentie.

Je kunt bijvoorbeeld verschillende herstelpunten bewaren:

• dagelijkse backups;
• wekelijkse backups;
• maandelijkse backups.

Wat verstandig is hangt af van:

• hoe vaak de website verandert;
• hoeveel data je kunt missen;
• hoeveel opslag beschikbaar is;
• hoe kritiek de website is.

20. Gebruik veilige bestandsoverdracht

Gebruik waar mogelijk geen onbeveiligde FTP-verbinding voor beheer.

Geef de voorkeur aan veilige protocollen zoals SFTP of andere versleutelde beheermethoden die je hostingprovider ondersteunt.

Verwijder bovendien oude FTP/SFTP-accounts die niet meer worden gebruikt.

Een account van een developer die twee jaar geleden aan je website werkte hoeft niet eeuwig actief te blijven.

21. Controleer WordPress-bestandsrechten

Bestandsrechten bepalen welke gebruikers en processen bestanden mogen lezen, wijzigen of uitvoeren.

Te ruime permissions kunnen risico's introduceren.

WordPress adviseert dat corebestanden in normale situaties alleen schrijfbaar zijn voor het account dat ze daadwerkelijk moet beheren.

Veelgebruikte configuraties gebruiken bijvoorbeeld rechten in de orde van:

• directories: 755;
• bestanden: 644;

maar de juiste instellingen hangen af van de serverarchitectuur, eigenaar/groep en hostingomgeving.

Kopieer daarom niet blind permissions uit een willekeurige tutorial.

Een instelling als 777 gebruiken omdat een plugin anders niet werkt is meestal een slecht idee.

Los liever het onderliggende ownership- of configuratieprobleem op.

22. Bescherm wp-config.php

wp-config.php is één van de belangrijkste bestanden van een WordPress-installatie.

Het bevat onder andere informatie over:

• databaseverbinding;
• WordPress-configuratie;
• authentication keys en salts;
• eventueel aanvullende secrets of configuratie.

Dit bestand verdient daarom extra bescherming.

WordPress adviseert in zijn hardeningdocumentatie expliciet aandacht te besteden aan de beveiliging van wp-config.php.

Zorg onder andere dat:

• bestandsrechten passend zijn;
• het bestand niet publiek als platte tekst kan worden opgevraagd;
• backups ervan niet publiek bereikbaar zijn;
• gevoelige gegevens niet onnodig worden gedeeld.

23. Gebruik sterke WordPress security keys en salts

In wp-config.php staan WordPress Authentication Unique Keys and Salts.

Deze worden gebruikt bij de beveiliging van authenticatiegegevens en cookies.

Gebruik willekeurig gegenereerde waarden.

WordPress adviseert sterke, random secret keys.

Wanneer je vermoedt dat sessies of credentials gecompromitteerd zijn, kan het vervangen van deze keys onderdeel zijn van je incidentrespons.

Het vervangen ervan maakt bestaande authenticatiecookies ongeldig, waardoor ingelogde gebruikers opnieuw moeten inloggen.

24. Overweeg file editing vanuit wp-admin uit te schakelen

WordPress biedt administrators standaard mogelijkheden om bestanden via de beheeromgeving te wijzigen, afhankelijk van de configuratie.

Op veel productiewebsites is dat niet noodzakelijk.

Je kunt file editing uitschakelen via wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Waarom kan dit nuttig zijn?

Wanneer een aanvaller toegang krijgt tot een administratoraccount, wil je het zo moeilijk mogelijk maken om vanuit het dashboard direct PHP-code te wijzigen.

Dit is geen vervanging voor goede authenticatie.

Het is een extra beveiligingslaag.

Let op: test wijzigingen in wp-config.php zorgvuldig en maak vooraf een backup.

25. Installeer plugins alleen uit betrouwbare bronnen

"Premium plugin gratis downloaden" is meestal geen slimme zoekopdracht.

Zogenaamde nulled plugins en themes kunnen:

• aangepaste code;
• backdoors;
• spam;
• verborgen administrators;
• malware;
• cryptominers

bevatten.

Gebruik plugins en thema's daarom vanuit:

• WordPress.org;
• de officiële leverancier;
• een betrouwbare commerciële marketplace;
• of je eigen gecontroleerde broncode.

Een licentie besparen is het risico van een gecompromitteerde bedrijfswebsite niet waard.

26. Installeer niet zomaar iedere securityplugin

Een securityplugin kan waardevol zijn.

Bijvoorbeeld voor:

• loginbescherming;
• 2FA;
• malwaredetectie;
• file integrity monitoring;
• audit logs;
• blokkeren van verdachte requests.

Maar:

meer securityplugins betekent niet automatisch meer beveiliging.

Meerdere plugins kunnen:

• dezelfde functies uitvoeren;
• conflicteren;
• performance verminderen;
• verschillende firewallregels toepassen;
• het beheer ingewikkelder maken.

Gebruik liever één goed gekozen oplossing die past bij je hostingomgeving.

Controleer bovendien welke beveiliging je hostingprovider al op server- of netwerkniveau uitvoert.

27. Bescherm het WordPress-loginformulier tegen misbruik

wp-login.php is bij vrijwel iedere WordPress-installatie bekend.

Dat is op zichzelf geen beveiligingslek.

Een aanvaller kan echter geautomatiseerd grote aantallen loginpogingen uitvoeren.

Maatregelen hiertegen kunnen zijn:

• rate limiting;
• beperking van mislukte loginpogingen;
• botdetectie;
• firewallregels;
• 2FA;
• CAPTCHA of vergelijkbare challenges waar passend.

De belangrijkste bescherming blijft echter:

sterke unieke credentials + 2FA.

Alleen /wp-login.php naar een geheime URL verplaatsen moet je niet beschouwen als fundamentele beveiliging.

28. Begrijp het verschil tussen bescherming en "security through obscurity"

Het verbergen van informatie kan soms bots verminderen.

Maar iets geheim proberen te houden is geen vervanging voor echte beveiliging.

Voorbeelden:

• login-URL wijzigen;
• WordPress-versie verbergen;
• databaseprefix veranderen;
• generator-tags verwijderen.

Dit kan bepaalde geautomatiseerde scans beïnvloeden, maar een serieuze aanvaller hoeft daar niet door gestopt te worden.

Investeer eerst in:

• updates;
• sterke authenticatie;
• 2FA;
• minimale rechten;
• veilige hosting;
• backups;
• monitoring;
• firewalling.

Daar zit de echte winst.

29. Schakel de REST API niet blind uit

Online securityhandleidingen adviseren soms:

Disable WordPress REST API.

Dat is te simplistisch.

De REST API is onderdeel van moderne WordPress-functionaliteit en wordt onder andere gebruikt door de Block Editor en plugininterfaces.

Het volledig uitschakelen kan WordPress-functionaliteit breken.

Publieke content die via de website toegankelijk is, kan doorgaans ook via publieke REST-endpoints beschikbaar zijn. Privégegevens vereisen normaal gesproken authenticatie, tenzij een plugin of maatwerkendpoint verkeerd is geïmplementeerd.

De betere aanpak is daarom:

• controleer welke endpoints je website aanbiedt;
• bescherm gevoelige endpoints correct;
• gebruik correcte authenticatie en permissions;
• beperk maatwerkendpoints wanneer nodig.

Niet:

"REST API bestaat, dus hij moet uit."

30. Controleer Application Passwords

WordPress heeft Application Passwords voor externe applicaties en API-koppelingen.

Dit zijn aparte credentials die aan een WordPress-gebruiker gekoppeld zijn.

Het voordeel is dat je bijvoorbeeld een integratie toegang kunt geven zonder het echte wachtwoord van die gebruiker te delen.

Een Application Password:

• is bedoeld voor applicaties en scripts;
• kan afzonderlijk worden ingetrokken;
• wordt gekoppeld aan een specifieke gebruiker;
• hoort via HTTPS te worden gebruikt.

Controleer periodiek:

Gebruikers → Profiel → Application Passwords

en verwijder credentials die niet meer worden gebruikt.

Gebruik bovendien één afzonderlijk Application Password per integratie.

Dus liever:

• CRM koppeling;
• Mobile app;
• Deployment script;

dan één credential voor alles.

Wanneer één integratie wordt beëindigd, kun je precies die credential intrekken.

31. Deel je hoofdwachtwoord niet met API's en externe diensten

Als een externe applicatie WordPress-toegang nodig heeft, geef die dienst dan niet automatisch het gewone administratorwachtwoord.

Gebruik waar mogelijk:

• Application Passwords;
• API keys;
• OAuth;
• serviceaccounts;
• of een andere daarvoor ontworpen authenticatiemethode.

Het voordeel is dat een afzonderlijke credential kan worden ingetrokken zonder het hoofdaccount volledig te wijzigen.

32. Controleer XML-RPC voordat je het uitschakelt

xmlrpc.php wordt al lange tijd besproken in WordPress-securityartikelen.

Sommige websites hebben XML-RPC niet nodig.

Andere diensten of integraties kunnen er wel afhankelijk van zijn.

Schakel het daarom niet blind uit omdat een checklist zegt dat dit "altijd veilig" is.

Controleer eerst:

• welke plugins je gebruikt;
• of externe publishingtools actief zijn;
• welke integraties afhankelijk zijn van XML-RPC;
• of je security- of hostinglaag misbruik al beperkt.

Wanneer je het niet nodig hebt en het structureel wordt misbruikt, kun je toegang beperken.

33. Gebruik een firewall

Een firewall kan kwaadaardig verkeer blokkeren voordat een request diep in WordPress wordt verwerkt.

Er bestaan verschillende lagen.

Web Application Firewall

Een WAF kan requests analyseren en bekende aanvalspatronen blokkeren.

Server-side firewall

Kan verbindingen of IP-adressen op infrastructuurniveau beperken.

CDN/edge firewall

Kan kwaadaardig verkeer al blokkeren voordat het je origin-server bereikt.

Welke oplossing het beste is hangt af van je hostingarchitectuur.

Een firewall is vooral effectief als onderdeel van een gelaagde beveiligingsstrategie.

Niet als vervanging voor updates.

34. Gebruik rate limiting

Een bot hoeft niet onbeperkt duizenden requests naar gevoelige endpoints te kunnen sturen.

Rate limiting kan bijvoorbeeld nuttig zijn voor:

• loginpagina's;
• password resets;
• bepaalde API-endpoints;
• zoekfunctionaliteit;
• formulieren;
• endpoints die vaak door bots worden misbruikt.

Doe dit zorgvuldig.

Te agressieve regels kunnen legitieme bezoekers blokkeren.

Bij webshops, API's en websites achter gedeelde netwerken moet je bijvoorbeeld rekening houden met normale verkeerspatronen.

35. Monitor mislukte loginpogingen

Eén verkeerd wachtwoord is normaal.

Tienduizend mislukte loginpogingen vanaf allerlei IP-adressen zijn interessanter.

Logging helpt je patronen herkennen.

Monitor bijvoorbeeld:

• succesvolle administratorlogins;
• mislukte logins;
• password resets;
• nieuwe gebruikers;
• nieuwe administrators;
• plugininstallaties;
• pluginactivaties;
• wijzigingen aan belangrijke instellingen.

Je hoeft niet iedere login handmatig te bekijken.

Het doel is afwijkend gedrag zichtbaar maken.

36. Gebruik audit logging op belangrijke websites

Voor een eenvoudige persoonlijke blog is uitgebreide logging misschien overdreven.

Voor een:

• WooCommerce-webshop;
• bedrijfswebsite;
• ledenplatform;
• website met meerdere administrators;
• organisatie met externe developers

is een audit log veel nuttiger.

Je kunt dan achteraf onderzoeken:

• wie inlogde;
• welke plugin werd geïnstalleerd;
• welke gebruiker administrator werd;
• wanneer instellingen veranderden;
• welke content werd aangepast.

Logs zijn vooral waardevol wanneer er daadwerkelijk een incident plaatsvindt.

37. Monitor bestanden op onverwachte wijzigingen

Malware probeert vaak persistent aanwezig te blijven.

Daarvoor kunnen bestanden worden:

• toegevoegd;
• gewijzigd;
• vervangen.

File integrity monitoring kan helpen onverwachte wijzigingen te signaleren.

Bijvoorbeeld:

• gewijzigd WordPress Core-bestand;
• onbekend PHP-bestand in uploads;
• aangepaste pluginbestanden;
• vreemde bestanden in wp-admin;
• onbekende code in een theme.

Niet iedere wijziging betekent malware.

Updates veranderen immers ook bestanden.

Het gaat om onverwachte wijzigingen die niet verklaard kunnen worden.

38. Controleer uploads

De WordPress uploads-directory hoort hoofdzakelijk mediabestanden te bevatten.

Wanneer je daar onverwachte uitvoerbare PHP-bestanden aantreft, verdient dat onderzoek.

Controleer ook plugins waarmee bezoekers bestanden kunnen uploaden.

Uploadfunctionaliteit moet onder andere rekening houden met:

• bestandstype;
• extensie;
• MIME-type;
• bestandsnaam;
• opslaglocatie;
• toegangsrechten.

Dit is vooral belangrijk bij maatwerkformulieren, ledenplatforms en documentportalen.

39. Bescherm formulieren tegen spam en misbruik

Contactformulieren zijn een populair doelwit voor bots.

Niet iedere bot probeert WordPress te hacken.

Sommige bots willen vooral:

• spam versturen;
• formulieren misbruiken;
• accounts registreren;
• resources verbruiken;
• kwetsbaarheden onderzoeken.

Gebruik daarom passende antispammaatregelen.

Bijvoorbeeld:

• honeypots;
• rate limiting;
• botdetectie;
• CAPTCHA waar noodzakelijk;
• server-side validatie.

Vertrouw nooit alleen op JavaScriptvalidatie in de browser.

40. Beveilig maatwerkcode correct

Heb je zelf een WordPress-plugin, thema of maatwerkfunctionaliteit ontwikkeld?

Dan verschuift een deel van de beveiligingsverantwoordelijkheid naar je eigen code.

Belangrijke principes zijn onder andere:

• valideer input;
• sanitize gegevens waar passend;
• escape output;
• controleer user capabilities;
• gebruik nonces tegen CSRF waar passend;
• gebruik veilige WordPress-databasefuncties;
• vertrouw nooit blind op gebruikersinput.

Veel klassieke webkwetsbaarheden zijn ook in WordPress relevant.

Denk aan:

• SQL Injection;
• Cross-Site Scripting (XSS);
• Cross-Site Request Forgery (CSRF);
• privilege escalation;
• onveilige uploads.

WordPress biedt veel ingebouwde functies om dit veilig af te handelen. Gebruik deze waar mogelijk in plaats van zelf beveiligingsmechanismen opnieuw uit te vinden.

41. Controleer custom REST API-endpoints

Wanneer developers eigen REST API-endpoints toevoegen, moeten de permissions correct worden ingesteld.

Een endpoint dat bijvoorbeeld klantgegevens retourneert mag niet per ongeluk publiek toegankelijk zijn.

Controleer bij maatwerk:

• authentication;
• authorization;
• permission_callback;
• inputvalidatie;
• output;
• rate limiting waar nodig.

Het feit dat een endpoint een ingewikkelde URL heeft maakt hem niet privé.

42. Bescherm secrets en API keys

WordPress-sites bevatten steeds meer externe integraties.

Bijvoorbeeld:

• payment APIs;
• e-mailproviders;
• AI-diensten;
• CRM;
• boekhouding;
• maps;
• shipping;
• ERP.

API keys en secrets mogen niet zomaar:

• in publieke JavaScriptbestanden;
• in Git-repositories;
• in screenshots;
• in supporttickets;
• in openbare backups

terechtkomen.

Behandel API credentials alsof het wachtwoorden zijn.

Wanneer een secret gelekt is:

rotate hem.

Alleen het bestand verwijderen waarin hij stond is niet voldoende wanneer iemand de credential al heeft gekopieerd.

43. Controleer Git-repositories en deployment

Ontwikkel je WordPress professioneel via Git?

Controleer dan of gevoelige bestanden niet per ongeluk worden gecommit.

Denk aan:

• .env;
• backups;
• database dumps;
• API keys;
• private keys;
• configuratiebestanden met credentials.

Gebruik passende .gitignore-regels en secret management.

Een privérepository verlaagt het risico, maar is geen excuus om secrets permanent in de repository te bewaren.

44. Bescherm databasecredentials

WordPress moet verbinding kunnen maken met zijn database.

Daarvoor zijn credentials nodig.

Geef de databasegebruiker alleen de rechten die noodzakelijk zijn voor de WordPress-installatie en voorkom dat databasebeheer publiek toegankelijk is zonder aanvullende beveiliging.

Gebruik bovendien niet dezelfde databasecredentials voor allerlei onafhankelijke websites wanneer je infrastructuur afzonderlijke accounts ondersteunt.

Segmentatie beperkt de schade wanneer één website wordt gecompromitteerd.

45. Een andere databaseprefix is geen magische beveiliging

Veel WordPress-securityhandleidingen adviseren:

Verander wp_ naar een willekeurige databaseprefix.

Dat kan bepaalde zeer primitieve aanvalspogingen verstoren, maar het is geen fundamentele securitymaatregel.

Een goed gebouwde SQL-injectionaanval hoeft niet noodzakelijk te vertrouwen op de standaardprefix.

Zie een aangepaste prefix daarom hooguit als een kleine aanvullende maatregel.

Niet als vervanging voor:

• veilige code;
• updates;
• correcte databasepermissions;
• inputvalidatie.

Ga bovendien niet zonder goede reden de prefix van een bestaande productiewebsite aanpassen. Dat kan meer problemen veroorzaken dan het oplost.

46. Gebruik security headers waar passend

HTTP security headers kunnen browsers aanvullende beveiligingsinstructies geven.

Voorbeelden zijn:

Content-Security-Policy (CSP)
Kan bepalen vanuit welke bronnen content mag worden geladen.

Strict-Transport-Security (HSTS)
Kan browsers instrueren een domein alleen via HTTPS te benaderen.

X-Content-Type-Options
Helpt bepaalde MIME-sniffingproblemen voorkomen.

Referrer-Policy
Bepaalt hoeveel referrerinformatie wordt meegestuurd.

Permissions-Policy
Kan toegang tot bepaalde browserfuncties beperken.

Maar wees voorzichtig.

Een verkeerde CSP kan bijvoorbeeld:

• scripts blokkeren;
• betalingen verstoren;
• analytics breken;
• fonts blokkeren;
• embedded content uitschakelen.

Implementeer security headers daarom gecontroleerd en test de website daarna volledig.

47. Gebruik HSTS alleen wanneer HTTPS volledig op orde is

HSTS kan een sterke beveiligingsmaatregel zijn.

Maar implementeer het pas wanneer je zeker weet dat:

• het volledige domein via HTTPS werkt;
• certificaten correct worden vernieuwd;
• relevante subdomeinen correct zijn ingericht;
• je begrijpt welke HSTS-instellingen je toepast.

Een verkeerde langdurige HSTS-configuratie kan lastig terug te draaien zijn vanuit browsers die de policy al hebben opgeslagen.

48. Houd SSL/TLS-certificaten in de gaten

Een verlopen certificaat is niet alleen vervelend voor bezoekers.

Het kan:

• browserwaarschuwingen veroorzaken;
• API-koppelingen breken;
• betalingen verstoren;
• monitoring laten falen.

Gebruik daarom automatische certificaatvernieuwing waar mogelijk en monitor of vernieuwing daadwerkelijk lukt.

49. Gebruik WordPress Site Health

WordPress heeft een ingebouwde functie:

Gereedschap → Sitediagnose

Site Health controleert verschillende onderdelen van je installatie en kan waarschuwingen geven over bijvoorbeeld:

• updates;
• PHP;
• HTTPS;
• plugins;
• thema's;
• REST API;
• scheduled events;
• configuratieproblemen.

WordPress beschouwt een gezonde website onder andere als up-to-date, goed onderhouden en veilig.

Site Health vervangt geen securityscan, maar is een uitstekend periodiek controlepunt.

50. Controleer cronjobs en scheduled tasks

Plugins kunnen geplande taken toevoegen.

Bijvoorbeeld voor:

• backups;
• e-mail;
• synchronisatie;
• WooCommerce;
• imports;
• cleanup;
• securityscans.

Controleer bij verdachte activiteit ook geplande taken.

Malware kan soms proberen persistentie te creëren door kwaadaardige code periodiek opnieuw uit te voeren.

Controleer zowel WordPress cronjobs als server-side cronjobs wanneer je daar toegang toe hebt.

51. Beveilig staging- en testomgevingen

Een stagingwebsite wordt verrassend vaak vergeten.

Bijvoorbeeld:

staging.example.be

De productieomgeving heeft:

• 2FA;
• firewall;
• updates;
• monitoring.

Maar staging gebruikt:

• oud wachtwoord;
• verouderde plugins;
• kopie van echte klantdata;
• geen firewall.

Een aanvaller maakt geen onderscheid tussen "productie" en "test".

Als staging toegang geeft tot gevoelige data of dezelfde infrastructuur gebruikt, kan het eveneens een waardevol doelwit zijn.

Beveilig staging daarom minimaal even serieus.

52. Laat testomgevingen geen onnodige persoonsgegevens bevatten

Wanneer je een productieomgeving naar staging kopieert, kopieer je mogelijk ook:

• klanten;
• bestellingen;
• e-mailadressen;
• formulieren;
• gebruikersaccounts.

Vraag jezelf af of die data werkelijk nodig is.

Waar mogelijk kun je persoonsgegevens anonimiseren of verwijderen.

Security gaat namelijk niet alleen om het voorkomen van een WordPress-hack, maar ook om het beperken van de impact wanneer iets misgaat.

53. Controleer oude subdomeinen en vergeten installaties

Soms is niet de hoofdwebsite het probleem.

Maar:

• old.example.be;
• test.example.be;
• dev.example.be;
• shop-old.example.be.

Een WordPress-installatie uit 2021 die niemand meer onderhoudt kan nog steeds online staan.

Maak daarom periodiek een inventarisatie van:

• domeinen;
• subdomeinen;
• WordPress-installaties;
• databases;
• stagingomgevingen.

Wat niet meer nodig is:

veilig verwijderen.

54. Beveilig lokale computers van beheerders

Je kunt WordPress perfect configureren, maar wanneer de laptop van een administrator malware bevat, kan een aanvaller mogelijk alsnog credentials stelen.

Beveilig daarom ook endpoints.

Denk aan:

• automatische OS-updates;
• browserupdates;
• malwarebescherming;
• schermvergrendeling;
• disk encryption;
• geen ongecontroleerde software;
• voorzichtigheid met browserextensions.

WordPress-security stopt niet bij de webserver.

55. Pas op voor phishing

Niet iedere WordPress-aanval is technisch.

Een aanvaller kan simpelweg een e-mail sturen:

"Critical WordPress vulnerability detected. Login immediately to install update."

De link leidt vervolgens naar een nagemaakte WordPress-loginpagina.

Daarom helpt zelfs een volledig gepatchte server niet tegen iedere aanval.

Train beheerders om:

• links te controleren;
• verdachte attachments niet te openen;
• niet via onverwachte e-mails in te loggen;
• wachtwoorden nooit te delen;
• 2FA-verzoeken niet blind goed te keuren.

56. Gebruik geen openbare wifi voor gevoelig beheer zonder passende bescherming

HTTPS beschermt veel netwerkverkeer, maar het blijft verstandig voorzichtig te zijn op onbekende of onbetrouwbare netwerken.

Beheer kritieke infrastructuur bij voorkeur vanaf vertrouwde apparaten en netwerken.

Gebruik indien je organisatie dit vereist aanvullende netwerkbeveiliging zoals een zakelijke VPN.

Belangrijker nog:

log nooit in op WordPress vanaf computers die je niet vertrouwt.

57. Monitor uptime én security

Uptime monitoring vertelt je of de website bereikbaar is.

Security monitoring probeert te signaleren of er iets ongewoons gebeurt.

Gebruik waar passend beide.

Interessante signalen zijn bijvoorbeeld:

• website offline;
• onverwachte redirects;
• gewijzigde homepage;
• malwarewaarschuwing;
• nieuw administratoraccount;
• onverwachte bestandswijzigingen;
• grote toename in loginpogingen;
• plotselinge serverbelasting.

Hoe sneller je een incident ontdekt, hoe kleiner de potentiële schade.

58. Zorg dat securitymeldingen daadwerkelijk iemand bereiken

Een fantastische securitytool die alerts stuurt naar:

[email protected]

waar niemand meer naar kijkt, heeft weinig waarde.

Controleer daarom:

• welk e-mailadres meldingen ontvangt;
• wie verantwoordelijk is;
• welke alerts urgent zijn;
• wat er buiten kantooruren gebeurt;
• wanneer actie nodig is.

Security is ook een proces.

Niet alleen software.

59. Maak een incident response-plan

Wat gebeurt er wanneer je morgen ontdekt dat je WordPress-site is gehackt?

Wie doet wat?

Een eenvoudig incidentplan kan bijvoorbeeld bevatten:

1. incident bevestigen;
2. website veiligstellen;
3. logs en bewijsmateriaal bewaren;
4. toegang beperken;
5. gecompromitteerde credentials intrekken;
6. oorzaak identificeren;
7. malware verwijderen of vanuit een schone backup herstellen;
8. kwetsbaarheid oplossen;
9. wachtwoorden en secrets roteren;
10. website opnieuw controleren;
11. monitoring aanscherpen;
12. bepalen of betrokken partijen moeten worden geïnformeerd.

Tijdens een incident wil je dit niet voor het eerst bedenken.

60. Verwijder malware niet zonder de oorzaak te vinden

Dit is een zeer belangrijke fout.

Stel dat je een kwaadaardig PHP-bestand vindt en verwijdert.

Website schoon?

Niet noodzakelijk.

Als de aanvaller binnenkwam via een kwetsbare plugin die nog steeds geïnstalleerd is, kan dezelfde website morgen opnieuw worden gehackt.

Na een compromis moet je dus twee vragen beantwoorden:

1. Wat heeft de aanvaller veranderd?

en:

2. Hoe is de aanvaller binnengekomen?

Alleen vraag één oplossen is onvoldoende.

61. Verander credentials na een beveiligingsincident

Wanneer een website daadwerkelijk is gecompromitteerd, moet je ervan uitgaan dat bepaalde secrets mogelijk zijn ingezien.

Afhankelijk van het incident kunnen daarom onder andere moeten worden gewijzigd:

• WordPress-wachtwoorden;
• hostingcredentials;
• SFTP/SSH-credentials;
• databasewachtwoord;
• API keys;
• Application Passwords;
• WordPress salts;
• e-mailcredentials;
• externe integratietokens.

Welke credentials precies moeten worden geroteerd hangt af van de omvang van het incident.

62. Vertrouw niet blind op een malware scanner

Een scan die zegt:

No malware found

is positief.

Maar het bewijst niet dat de website gegarandeerd schoon is.

Scanners kunnen bekende patronen detecteren, maar aanvallers kunnen:

• code obfusceren;
• nieuwe technieken gebruiken;
• legitieme bestanden aanpassen;
• toegang buiten WordPress behouden.

Combineer scanners daarom met:

• file integrity checks;
• logging;
• handmatige analyse;
• serverlogs;
• gebruikerscontrole;
• controle van scheduled tasks.

Bij een serieus incident is professionele analyse vaak verstandiger dan tientallen willekeurige cleanupplugins installeren.

63. Beveilig WooCommerce extra zorgvuldig

Een WooCommerce-site verwerkt doorgaans meer gevoelige processen dan een gewone blog.

Denk aan:

• klantaccounts;
• bestellingen;
• adressen;
• betaalprocessen;
• kortingscodes;
• API-koppelingen;
• voorraad;
• webhooks.

Daarom verdient WooCommerce aanvullende aandacht.

Controleer onder andere:

• administratoraccounts;
• Shop Manager-accounts;
• payment plugins;
• webhooks;
• REST API keys;
• Application Passwords;
• externe ERP- of boekhoudkoppelingen;
• backups;
• audit logs.

En update WooCommerce-extensies zorgvuldig.

64. Bewaar geen betaalkaartgegevens wanneer dat niet nodig is

Laat betalingsgegevens waar mogelijk verwerken door gespecialiseerde betalingsproviders en volg hun integratierichtlijnen.

Sla geen gevoelige kaartgegevens zelf op "omdat dat handig is" wanneer je daar geen expliciete technische en compliancebasis voor hebt.

Hoe minder gevoelige data je zelf bewaart, hoe kleiner de potentiële impact van een datalek.

65. Controleer webhooks en API-integraties

Moderne WordPress- en WooCommerce-sites communiceren steeds vaker met externe systemen.

Bijvoorbeeld:

WordPress → CRM
WooCommerce → boekhouding
WooCommerce → fulfilment
Formulier → marketingplatform

Controleer periodiek:

• welke integraties bestaan;
• welke credentials ze gebruiken;
• welke rechten ze hebben;
• of ze nog nodig zijn;
• wanneer ze voor het laatst zijn gebruikt.

Een API key uit 2022 voor een dienst die je niet meer gebruikt hoeft niet actief te blijven.

66. Gebruik least privilege voor API-koppelingen

Een integratie die alleen blogposts hoeft te lezen heeft geen volledige administratorrechten nodig.

Een rapportagetool die alleen orders uitleest hoeft misschien geen producten te kunnen verwijderen.

Pas ook op API-niveau het principe van minimale rechten toe.

Dat beperkt de schade wanneer een API credential wordt gestolen.

67. Houd logs lang genoeg bij om incidenten te onderzoeken

Wanneer je vandaag ontdekt dat een aanval drie weken geleden begon, zijn logs van alleen de laatste 24 uur weinig behulpzaam.

Bepaal daarom een passende retentie voor:

• access logs;
• error logs;
• securitylogs;
• audit logs;
• firewalllogs.

Hoe lang je ze moet bewaren hangt af van je organisatie, opslagmogelijkheden en privacyvereisten.

Bewaar logs bovendien veilig.

Logs kunnen zelf gevoelige informatie bevatten.

68. Bescherm backups alsof het productiegegevens zijn

Een databasebackup kan net zo gevoelig zijn als de live database.

Misschien zelfs gevoeliger, omdat hij gemakkelijk als één bestand kan worden gekopieerd.

Bescherm backupopslag daarom met:

• sterke authenticatie;
• beperkte toegangsrechten;
• encryptie waar passend;
• logging;
• retentiebeleid.

Een publiek bereikbare .sql-backup is een ernstig beveiligingsprobleem.

69. Maak security onderdeel van regulier onderhoud

Security is geen project dat je één keer afrondt.

Een veilige website in januari kan in augustus nieuwe risico's hebben.

Waarom?

Omdat:

• nieuwe kwetsbaarheden worden ontdekt;
• medewerkers veranderen;
• nieuwe plugins worden geïnstalleerd;
• API-koppelingen worden toegevoegd;
• PHP-versies verouderen;
• domeinen veranderen;
• backups kunnen stoppen;
• certificaten kunnen verlopen.

Maak daarom een periodieke securitycheck.

Maandelijkse WordPress Security Checklist

Controleer minimaal regelmatig:

• WordPress Core-updates

• pluginupdates

• theme-updates

• PHP-status

• administratoraccounts

• ongebruikte gebruikers

• ongebruikte plugins

• Application Passwords

• backups

• securityalerts

• uptime

• verdachte bestandswijzigingen

• Site Health

• SSL/TLS-certificaat

• stagingomgevingen

Voor kritieke websites moeten sommige controles uiteraard veel vaker plaatsvinden.

De belangrijkste WordPress-securitymaatregelen op volgorde

Als je vandaag maar een beperkt aantal dingen kunt doen, begin dan hiermee:

1. Update alles

WordPress, plugins, thema en serveromgeving.

2. Activeer 2FA

Minimaal voor alle accounts met beheerdersrechten.

3. Gebruik unieke wachtwoorden

Ook voor hosting, e-mail, DNS en externe diensten.

4. Verwijder ongebruikte software en accounts

Wat niet bestaat kan ook niet via die route worden misbruikt.

5. Maak betrouwbare externe backups

En test of je ze kunt herstellen.

6. Beperk gebruikersrechten

Niet iedereen hoeft administrator te zijn.

7. Gebruik HTTPS

Voor de volledige website.

8. Beveilig hosting en domeinaccounts

WordPress is maar één onderdeel van de infrastructuur.

9. Monitor de website

Je wilt een incident zo snel mogelijk ontdekken.

10. Maak een herstelplan

Zorg dat je weet wat je moet doen wanneer er toch iets misgaat.

Veelgemaakte fouten bij WordPress-beveiliging

"Ik heb een securityplugin, dus mijn website is veilig"

Een plugin kan helpen, maar kan geen slechte wachtwoorden, kwetsbare software, onveilige hosting en ontbrekende backups volledig compenseren.

"Ik gebruik een ingewikkelde login-URL"

Dat kan bots verminderen, maar is geen vervanging voor 2FA en sterke credentials.

"We maken backups op dezelfde server"

Dat beschermt onvoldoende tegen problemen waarbij de hele omgeving verloren gaat.

"Alle medewerkers zijn administrator"

Onnodig en riskant.

"Deze plugin is gedeactiveerd, dus ik hoef hem niet te updaten"

Als je hem niet meer nodig hebt, verwijder hem.

"De website gebruikt HTTPS, dus hij is veilig"

HTTPS beschermt netwerkverkeer. Het repareert geen kwetsbare plugin.

"Ik moet de REST API uitschakelen"

Niet blind doen. Moderne WordPress-functionaliteit kan ervan afhankelijk zijn.

"We zijn te klein om gehackt te worden"

Veel aanvallen zijn geautomatiseerd.

Een bot controleert niet eerst hoeveel medewerkers je bedrijf heeft voordat hij een kwetsbare plugin probeert te misbruiken.

Is WordPress zelf veilig?

WordPress kan veilig worden gebruikt, maar de veiligheid van een website hangt af van de volledige omgeving.

Een actuele WordPress-installatie op goede hosting met:

• onderhouden plugins;
• sterke authenticatie;
• 2FA;
• minimale gebruikersrechten;
• backups;
• monitoring;
• veilige maatwerkcode

is een totaal andere situatie dan een WordPress-installatie met plugins uit 2019 en één gedeeld administratorwachtwoord.

De vraag is daarom niet alleen:

"Is WordPress veilig?"

Maar vooral:

"Is deze specifieke WordPress-installatie goed onderhouden en beveiligd?"

Heb ik een WordPress-securityplugin nodig?

Niet noodzakelijk voor iedere functie.

Sommige beveiligingsmaatregelen kunnen op hosting-, server-, CDN- of infrastructuurniveau beter worden uitgevoerd.

Een securityplugin kan echter nuttig zijn voor bijvoorbeeld:

• 2FA;
• loginbescherming;
• audit logging;
• malwaredetectie;
• file integrity monitoring.

Controleer voordat je een plugin installeert welke beveiliging je hostingprovider al levert.

Voorkom onnodige overlap.

Hoe vaak moet ik WordPress updaten?

Securityupdates moet je niet onnodig lang uitstellen.

Voor reguliere functionele updates kun je afhankelijk van je website een gecontroleerd updateproces gebruiken.

Bij kritieke websites is het verstandig:

1. backup maken;
2. staging testen;
3. update uitvoeren;
4. functionaliteit controleren;
5. monitoring bekijken.

Het belangrijkste is dat updates geen taak worden die maanden blijft liggen.

Hoe vaak moet ik een WordPress-backup maken?

Dat hangt af van hoeveel data je kunt verliezen.

Een website die één keer per maand wordt aangepast heeft andere eisen dan een WooCommerce-webshop die iedere vijf minuten een bestelling ontvangt.

Stel jezelf de vraag:

Hoeveel gegevens mogen we maximaal verliezen?

Als het antwoord "één uur" is, dan is één backup per week duidelijk onvoldoende.

Wat moet ik doen als mijn WordPress-website gehackt is?

Ga niet onmiddellijk willekeurige bestanden verwijderen zonder eerst de situatie te begrijpen.

Een goede aanpak is:

1. beperk verdere schade;
2. bewaar relevante logs;
3. bepaal wat er is gewijzigd;
4. identificeer de toegangsmethode;
5. verwijder malware of herstel vanuit een bekende schone backup;
6. patch de kwetsbaarheid;
7. roteer mogelijk gelekte credentials;
8. controleer gebruikers en integraties;
9. controleer de website opnieuw;
10. monitor intensiever na herstel.

Bij een bedrijfswebsite met gevoelige gegevens kan daarnaast juridische of privacygerelateerde opvolging noodzakelijk zijn.

WordPress-beveiliging is een proces, geen plugin

De belangrijkste les uit deze WordPress Security Checklist voor 2026 is eenvoudig:

security bestaat uit lagen.

Een veilige WordPress-omgeving combineert:

• actuele software;
• betrouwbare hosting;
• sterke authenticatie;
• 2FA;
• minimale gebruikersrechten;
• veilige configuratie;
• correcte bestandsrechten;
• HTTPS;
• betrouwbare backups;
• monitoring;
• logging;
• een herstelprocedure.

Geen enkele maatregel is op zichzelf voldoende.

2FA helpt niet wanneer een aanvaller via een kwetsbare plugin willekeurige code kan uitvoeren.

Een firewall helpt niet wanneer iemand het gedeelde administratorwachtwoord kent.

Een backup helpt niet voorkomen dat een website wordt aangevallen, maar kan wel het verschil betekenen tussen een incident van een uur en dagenlang gegevensverlies.

De beste WordPress-beveiliging ontstaat daarom door niet te zoeken naar één magische securityplugin, maar door de volledige omgeving structureel te onderhouden.

Een veilige WordPress-website begint ook bij de hostingomgeving

WordPress-security stopt niet bij WordPress zelf.

Ook de webserver, PHP-versie, database, netwerkbeveiliging, backups en toegangscontrole spelen een belangrijke rol.

Controleer daarom of je hostingomgeving aansluit bij de beveiligingseisen van je website en of belangrijke functies zoals backups, actuele PHP-versies, HTTPS en passende beveiligingsmaatregelen beschikbaar zijn.

Heb je vragen over de technische beveiliging van je WordPress-hosting? Dan kun je uiteraard contact opnemen met Actiefhost om samen te bekijken welke maatregelen voor jouw website relevant zijn.

Het belangrijkste is echter dat WordPress-security onderdeel wordt van regulier beheer.

Niet iets waar je pas naar kijkt nadat er iets mis is gegaan.