WordPress beveiligen:
de complete gids
Elk artikel over WordPress beveiliging geeft dezelfde tips: installeer Wordfence, gebruik sterke wachtwoorden, houd alles up-to-date. Dat is niet verkeerd, maar het is het absolute minimum. Echte beveiliging begint op de server, gaat door HTTP headers en Content Security Policy, en eindigt bij WordPress zelf. In deze gids behandelen we alles wat de meeste artikelen overslaan, gebaseerd op 21+ jaar ervaring met het beveiligen van WordPress websites.
Waarom een beveiligingsplugin niet genoeg is
Zoek op "WordPress beveiligen" en je vindt tientallen artikelen die allemaal hetzelfde zeggen: installeer Wordfence of Sucuri, gebruik sterke wachtwoorden, update je plugins. Die adviezen zijn niet fout. Ze zijn incompleet. Alsof je adviseert om je voordeur op slot te doen maar vergeet te vermelden dat het raam open staat, de achterdeur geen slot heeft en de muren van karton zijn.
Het probleem met beveiligingsplugins als enige verdediging is fundamenteel. Een WordPress plugin draait binnen WordPress. Het kan alleen beschermen tegen aanvallen die via WordPress binnenkomen. Maar een groot deel van de aanvallen richt zich op de lagen eronder: de webserver, PHP, de database, het besturingssysteem. Een plugin die binnen WordPress draait kan niet beschermen tegen een kwetsbaarheid in PHP zelf, een verkeerd geconfigureerde webserver of een database die publiek toegankelijk is via een subdomein.
De drie lagen van WordPress beveiliging
Effectieve beveiliging werkt op drie lagen die samen een verdediging in de diepte vormen:
- Laag 1: Server en infrastructuur — het besturingssysteem, de webserver, PHP, de database, firewalls, isolatie tussen websites. Dit is de fundering. Als deze laag zwak is, maakt het niet uit wat je in WordPress installeert.
- Laag 2: HTTP headers en transport — HTTPS, Content Security Policy, beveiligingsheaders die de browser instrueren hoe content moet worden behandeld. Deze laag beschermt je bezoekers en voorkomt een hele categorie aanvallen die plugins niet kunnen tegenhouden.
- Laag 3: WordPress zelf — hardening van de configuratie, het minimaliseren van het aanvalsoppervlak, sterke authenticatie, het blokkeren van misbruikte endpoints. Dit is waar plugins een rol spelen, maar lang niet de enige oplossing zijn.
De meeste artikelen behandelen alleen laag 3 en dan nog oppervlakkig. Wij behandelen alle drie de lagen grondig. Want beveiliging die alleen op de bovenste laag werkt is geen beveiliging. Het is een illusie van beveiliging.
Laag 1: server beveiliging is de fundering
Stel je voor: je plaatst een gepantserde deur in een houten schuurtje. De deur is onbreekbaar, maar een aanvaller trapt gewoon door de muur. Dat is precies wat er gebeurt als je een beveiligingsplugin installeert op een server die niet goed is geconfigureerd. De plugin beschermt WordPress, maar de server eronder staat wagenwijd open.
Website isolatie met CloudLinux
Op een standaard shared hosting server delen tientallen of soms honderden websites dezelfde omgeving. Als een van die websites gehackt wordt, heeft de aanvaller potentieel toegang tot alle andere websites op dezelfde server. Dat is geen theoretisch risico. Het is een van de meest voorkomende manieren waarop hacks zich verspreiden: een vergeten testsite met een verouderde plugin wordt gehackt en de aanvaller springt van daaruit naar de productiesite van een ander bedrijf op dezelfde server.
CloudLinux lost dit op door elke website in een eigen geisoleerde omgeving (een zogenaamde CageFS) te draaien. Elke website krijgt zijn eigen PHP processen, zijn eigen limieten voor geheugen en CPU, en ziet letterlijk de bestanden van andere websites niet. Als website A gehackt wordt, kan de aanvaller niet bij website B, C of D. Ze bestaan simpelweg niet vanuit het perspectief van website A.
Daarnaast beperkt CloudLinux de resources per website. Dat betekent dat als een aanvaller een website compromitteert en probeert de server te overbelasten (voor crypto mining of als onderdeel van een DDoS netwerk), alleen die ene website vertraagt. De rest van de server draait gewoon door. Dit is geen luxe. Dit is hoe professionele hosting hoort te werken.
Actieve bescherming met Imunify360
Imunify360 is een server beveiligingsplatform dat op meerdere niveaus beschermt. Het combineert een Web Application Firewall (WAF), een Intrusion Detection and Prevention System (IDS/IPS), realtime malware scanning, proactieve verdediging en reputatie management in een geintegreerde oplossing die op serverniveau draait.
Het verschil met een WordPress plugin als Wordfence is fundamenteel. Imunify360 draait op het besturingssysteem, niet in WordPress. Het ziet al het verkeer dat naar de server komt voordat het WordPress bereikt. Het kan aanvallen blokkeren op netwerkniveau, voordat de aanvaller ook maar een PHP bestand kan aanroepen. Een WordPress plugin kan per definitie alleen reageren nadat PHP al is geladen en WordPress al draait. Op dat punt is de aanvaller al een stuk verder.
Concrete bescherming die Imunify360 biedt:
- Proactieve verdediging — analyseert PHP scripts in realtime en blokkeert kwaadaardig gedrag nog voordat de code wordt uitgevoerd. Detecteert obfuscated code, code injectie en bekende aanvalspatronen.
- Malware scanning — scant alle bestanden op de server continu. Nieuwe bestanden worden onmiddellijk gecontroleerd. Geinfecteerde bestanden worden automatisch in quarantaine geplaatst.
- Web Application Firewall — filtert inkomend verkeer en blokkeert bekende aanvalspatronen (SQL injectie, Cross-Site Scripting, Local en Remote File Inclusion) op serverniveau.
- Brute force bescherming — detecteert en blokkeert brute force aanvallen op alle inlogpagina's, niet alleen WordPress maar ook FTP, e-mail en SSH.
- Reputatiebeheer — houdt bij welke IP adressen kwaadaardig gedrag vertonen en blokkeert ze preventief, gebaseerd op een wereldwijd netwerk van meldingen.
Web Application Firewall (WAF)
Een Web Application Firewall zit tussen de bezoeker en je website. Het analyseert elk verzoek voordat het WordPress bereikt en blokkeert verzoeken die er verdacht uitzien. Dit omvat:
- SQL injectie — pogingen om database queries te manipuleren via URL parameters of formuliervelden.
- Cross-Site Scripting (XSS) — pogingen om kwaadaardige JavaScript in te voegen die wordt uitgevoerd in de browser van bezoekers.
- Remote File Inclusion (RFI) — pogingen om externe bestanden te laden en uit te voeren op de server.
- Local File Inclusion (LFI) — pogingen om lokale bestanden te lezen die niet bedoeld zijn voor publieke toegang (zoals wp-config.php).
- Directory traversal — pogingen om buiten de webroot te navigeren en systeembestanden te lezen.
Een WAF op serverniveau (ModSecurity, Imunify360 WAF) is effectiever dan een plugin gebaseerde oplossing omdat het verzoeken kan blokkeren voordat PHP wordt geladen. Het verwerkt regels op het niveau van de webserver, wat sneller en veiliger is dan dezelfde filtering in PHP uitvoeren.
PHP versie: het meest onderschatte beveiligingsrisico
PHP is de programmeertaal waar WordPress op draait. Elke PHP versie heeft een beperkte levensduur: actieve ontwikkeling, daarna alleen beveiligingspatches, daarna helemaal geen ondersteuning meer. PHP versies ouder dan 8.2 ontvangen geen beveiligingspatches meer. Bekende kwetsbaarheden in die versies worden nooit gedicht.
Bij vrijwel elke gehackte website die wij opschonen of scannen is de PHP versie jaren verouderd. Het is een van de eenvoudigste en meest effectieve beveiligingsmaatregelen die er bestaan: update PHP naar de meest recente versie. Maar het wordt verrassend vaak vergeten of uitgesteld, soms uit angst dat plugins niet compatibel zijn. Die angst is grotendeels onterecht. De meeste plugins zijn allang compatible met moderne PHP versies. En een enkele incompatibele plugin is een klein probleem vergeleken met een server die draait op een PHP versie met bekende beveiligingslekken.
Dagelijkse backups met retentie
Backups voorkomen geen hack maar ze beperken de schade drastisch. Een goede backup strategie heeft drie kenmerken: dagelijkse uitvoering, retentie van minimaal 30 dagen en opslag op een fysiek gescheiden locatie. Dagelijks zodat je nooit meer dan 24 uur aan data verliest. 30 dagen retentie omdat veel hacks pas na weken of maanden worden ontdekt en je dan terug moet kunnen naar een punt voor de hack. En gescheiden opslag zodat een aanvaller die de server compromitteert niet ook de backups kan verwijderen of versleutelen.
Bij onze hosting zijn dagelijkse backups met 30 dagen retentie standaard inbegrepen. Dat is geen extra dienst. Het is een basisvoorziening die bij elke professionele hosting omgeving standaard zou moeten zijn. Meer over onze hosting.
Laag 2: HTTP beveiligingsheaders en Content Security Policy
HTTP beveiligingsheaders zijn instructies die je server meestuurt met elke pagina die wordt geladen. Ze vertellen de browser van je bezoeker hoe die de content moet behandelen: welke scripts mogen draaien, of de pagina in een iframe mag worden geladen, of de browser HTTPS moet afdwingen. Het zijn onzichtbare beveiligingslagen die een hele categorie aanvallen voorkomen, en ze worden door de meeste WordPress websites niet gebruikt.
Dit is geen obscure techniek voor beveiligingsexperts. Het zijn basale maatregelen die elke website zou moeten implementeren. Laten we ze een voor een doorlopen.
Content Security Policy (CSP): de belangrijkste header die bijna niemand gebruikt
Content Security Policy is de krachtigste HTTP beveiligingsheader die er bestaat en tegelijkertijd de meest verwaarloosde. Een CSP vertelt de browser exact welke bronnen (scripts, stylesheets, afbeeldingen, fonts, verbindingen) mogen worden geladen en van welke domeinen ze mogen komen. Alles wat niet in het beleid staat, wordt geblokkeerd.
Waarom is dat zo belangrijk? Omdat het de meest effectieve bescherming is tegen Cross-Site Scripting (XSS), een van de meest voorkomende aanvallen op websites. Bij een XSS aanval slaagt een aanvaller erin om kwaadaardig JavaScript in te voegen in een webpagina. Dat script wordt uitgevoerd in de browser van de bezoeker en kan sessiegegevens stelen, formulierdata onderscheppen, de pagina manipuleren of de bezoeker doorsturen naar een phishing site.
Met een goede CSP werkt die aanval niet, zelfs als de aanvaller erin slaagt om het script in te voegen. De browser weigert het script uit te voeren omdat het niet op de goedgekeurde lijst staat. Het is een beveiligingslaag die werkt onafhankelijk van wat er op de server gebeurt.
Een voorbeeld van een CSP header zoals wij die implementeren:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; font-src 'self' data:; connect-src 'self'; frame-src 'self'; base-uri 'self'; form-action 'self';
Wat dit beleid zegt:
- default-src 'self' — standaard mag alleen content van het eigen domein worden geladen.
- script-src 'self' — scripts mogen alleen van het eigen domein komen. Geen externe scripts van Google, Facebook, analyticspartijen of advertentienetwerken.
- style-src 'self' 'unsafe-inline' — stylesheets van het eigen domein plus inline styles (nodig voor veel WordPress functionaliteit).
- img-src 'self' data: blob: — afbeeldingen van het eigen domein, plus data URIs en blobs (voor bijvoorbeeld SVG icons en dynamisch gegenereerde afbeeldingen).
- connect-src 'self' — AJAX verzoeken en WebSocket verbindingen alleen naar het eigen domein.
- frame-src 'self' — iframes alleen van het eigen domein (of specifiek toegestane domeinen zoals OpenStreetMap).
- form-action 'self' — formulieren mogen alleen naar het eigen domein worden verstuurd. Voorkomt dat een aanvaller een formulier manipuleert om data naar een externe server te sturen.
Het probleem met de meeste WordPress websites is dat een strikte CSP niet werkt met Google Analytics, Facebook Pixel, Google Fonts, externe advertentiescripts en andere third party diensten. Je moet al die externe domeinen toevoegen aan je CSP, en dan verliest het beleid zijn kracht. Een website die privacy first bouwt, zonder externe scripts en tracking, kan een veel striktere CSP implementeren. Dat is precies wat wij doen.
Strict-Transport-Security (HSTS)
HSTS dwingt HTTPS af. Nadat een browser de HSTS header heeft ontvangen, weigert die browser gedurende de opgegeven periode (max-age) om de website via onversleuteld HTTP te laden. Zelfs als de bezoeker expliciet http:// typt. Zelfs als een aanvaller probeert een downgrade aanval uit te voeren (het verkeer terugschakelen van HTTPS naar HTTP om het te kunnen afluisteren).
Een goede HSTS header ziet er zo uit: Strict-Transport-Security: max-age=31536000; includeSubDomains. Dit vertelt de browser: onthoud voor een jaar dat deze website en alle subdomeinen uitsluitend via HTTPS bereikbaar zijn.
Zonder HSTS is je website kwetsbaar voor SSL stripping aanvallen, vooral op openbare wifi netwerken. Een aanvaller die het netwerk beheert kan het HTTPS verkeer onderscheppen en terugschakelen naar HTTP, waarna alle data onversleuteld over het netwerk gaat. HSTS voorkomt dat.
X-Content-Type-Options
De header X-Content-Type-Options: nosniff voorkomt dat browsers bestanden interpreteren als een ander type dan aangegeven. Zonder deze header kan een aanvaller een bestand uploaden dat eruitziet als een afbeelding maar eigenlijk een script is, en sommige browsers zullen het als script uitvoeren. Met nosniff respecteert de browser strikt het MIME type dat de server aangeeft. Een afbeelding is een afbeelding, niet een vermomd script.
X-Frame-Options
De header X-Frame-Options: SAMEORIGIN voorkomt dat je website in een iframe op een andere website wordt geladen. Dit beschermt tegen clickjacking: een aanval waarbij je website onzichtbaar wordt geladen in een iframe op een kwaadaardige pagina, en de bezoeker denkt dat die op de kwaadaardige pagina klikt maar eigenlijk acties uitvoert op jouw website (inloggen, wachtwoord wijzigen, bestelling plaatsen).
Referrer-Policy
De header Referrer-Policy: strict-origin-when-cross-origin controleert hoeveel informatie de browser meestuurt wanneer een bezoeker van jouw website naar een andere website navigeert. Zonder deze header stuurt de browser de volledige URL mee, inclusief eventuele gevoelige parameters (zoektermen, sessieparameters, interne paden). Met strict-origin-when-cross-origin stuurt de browser bij extern verkeer alleen het domein mee, niet het volledige pad.
Permissions-Policy
De Permissions-Policy header specificeert welke browser functies je website mag gebruiken. Je kunt hiermee expliciet aangeven dat je website geen toegang nodig heeft tot de camera, microfoon, locatie en andere gevoelige browser APIs. Ons beleid: Permissions-Policy: camera=(), microphone=(), geolocation=(), interest-cohort=(). Dat laatste, interest-cohort, blokkeert Google's FLoC (Federated Learning of Cohorts), een tracking mechanisme dat Google in Chrome heeft ingebouwd.
Waarom de meeste WordPress websites geen goede headers hebben
Het implementeren van beveiligingsheaders op een WordPress website is technisch niet moeilijk. Het kan via de webserver configuratie (.htaccess op Apache/LiteSpeed, nginx.conf op Nginx) of via een plugin. Maar er zijn twee redenen waarom de meeste sites het niet hebben:
Ten eerste: kennis. Veel webbureaus en freelancers die WordPress websites bouwen kennen deze headers niet. Ze installeren een theme, voegen plugins toe en leveren op. Server configuratie en HTTP headers vallen buiten hun expertise.
Ten tweede: incompatibiliteit met third party scripts. Zodra je Google Analytics, Facebook Pixel, Google Fonts, HotJar, een chatwidget of advertentiescripts gebruikt, moet je al die domeinen toevoegen aan je CSP. En elke externe dienst die je toevoegt, verzwakt je beveiligingsbeleid. Een website die afhankelijk is van tien externe diensten kan geen strikte CSP implementeren. Dat is een van de vele redenen waarom privacy first bouwen niet alleen beter is voor de privacy van je bezoekers, maar ook voor de beveiliging van je website.
Laag 3: WordPress hardening, verder dan de standaard tips
Na server beveiliging en HTTP headers komen we bij WordPress zelf. Hier is waar de meeste artikelen beginnen en eindigen. Wij beginnen hier pas na twee lagen fundament. Maar deze laag is wel degelijk belangrijk. Een goed beveiligde server met goede HTTP headers beschermt tegen externe aanvallen. WordPress hardening beschermt tegen aanvallen die specifiek gericht zijn op WordPress functionaliteit.
wp-config.php beveiligen
Het bestand wp-config.php is het gevoeligste bestand in je hele WordPress installatie. Het bevat je database credentials (gebruikersnaam, wachtwoord, hostnaam, databasenaam), je authentication keys en salts, je tabelprefix en eventueel andere gevoelige configuratie. Een aanvaller die dit bestand kan lezen, heeft de sleutels tot je complete website.
Basismaatregelen voor wp-config.php:
- Blokkeer toegang via de browser — je webserver moet dit bestand nooit serveren aan een browser. Op Apache/LiteSpeed doe je dit met een .htaccess regel, op Nginx met een location block. Verrassend veel websites hebben dit niet geconfigureerd. Onze scanner controleert dit specifiek.
- Unieke authentication keys en salts — WordPress gebruikt deze voor het versleutelen van sessiecookies. Gebruik de officiële WordPress salt generator voor unieke waarden. Na een hack: vernieuw ze onmiddellijk. Dit logt alle bestaande sessies uit.
- Bestandsbewerking uitschakelen — voeg
define('DISALLOW_FILE_EDIT', true);toe aan wp-config.php. Dit schakelt de ingebouwde code editor in het WordPress dashboard uit. Als een aanvaller admin toegang krijgt, kan die niet direct PHP code bewerken via het dashboard. - Bestandsinstallatie uitschakelen — voeg
define('DISALLOW_FILE_MODS', true);toe aan wp-config.php. Dit gaat een stap verder: het schakelt ook de mogelijkheid uit om plugins en themes te installeren of te updaten via het dashboard. Updates worden dan alleen via de server gedaan (SFTP of command line), wat veiliger is. - Debug modus uitschakelen in productie —
define('WP_DEBUG', false);voorkomt dat foutmeldingen met gevoelige informatie (bestandspaden, database queries) worden getoond aan bezoekers.
Database beveiliging
WordPress gebruikt standaard het tabelprefix wp_. Elke WordPress installatie die het standaard prefix behoudt is kwetsbaarder voor geautomatiseerde SQL injectie aanvallen, omdat de aanvaller de tabelnamen al kent. Verander het prefix naar iets unieks bij de installatie. Bij een bestaande site is het achteraf wijzigen technisch mogelijk maar riskant en moet zorgvuldig worden gedaan.
Beperk de database gebruiker tot alleen de rechten die WordPress nodig heeft: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX en DROP. Geef nooit GRANT of SUPER rechten aan de WordPress database gebruiker. Als een aanvaller via SQL injectie de database bereikt, beperkt dit wat die kan doen.
Bestandspermissies
Correcte bestandspermissies zijn essentieel. De vuistregels:
- Directories: 755 — eigenaar mag lezen, schrijven en uitvoeren. Groep en anderen mogen alleen lezen en uitvoeren.
- Bestanden: 644 — eigenaar mag lezen en schrijven. Groep en anderen mogen alleen lezen.
- wp-config.php: 600 of 640 — alleen de eigenaar (en eventueel de groep) mag lezen. Niemand anders.
Permissies die te ruim zijn (777 of 666) staan elke gebruiker op de server toe om bestanden te lezen, wijzigen of uitvoeren. Op een shared hosting omgeving zonder CloudLinux isolatie betekent dat dat een gehackte website op dezelfde server je bestanden kan lezen en wijzigen.
XML-RPC uitschakelen
XML-RPC is een oud protocol dat WordPress gebruikt voor communicatie met externe diensten en mobiele apps. In de praktijk wordt het vrijwel niet meer gebruikt voor legitieme doeleinden (de REST API heeft die functie overgenomen), maar het wordt wel actief misbruikt voor twee soorten aanvallen:
- Brute force via system.multicall — XML-RPC staat toe om honderden inlogpogingen in een enkel verzoek te bundelen. Waar een brute force aanval via de reguliere login pagina duizenden individuele verzoeken vereist (die gemakkelijk te detecteren en blokkeren zijn), kan een aanvaller via XML-RPC honderden wachtwoorden per verzoek proberen. Veel brute force beveiligingsmaatregelen detecteren dit niet omdat het technisch een enkel verzoek is.
- DDoS amplificatie via pingback — de pingback functie van XML-RPC kan worden misbruikt om DDoS aanvallen te versterken. De aanvaller stuurt pingback verzoeken naar honderden WordPress sites met het IP adres van het doelwit als bronurl. Alle WordPress sites sturen vervolgens verzoeken naar het doelwit. Jouw website wordt onbewust onderdeel van een DDoS aanval.
Schakel XML-RPC volledig uit, inclusief de X-Pingback header en pingbacks. De kans dat je het nodig hebt is nihil. De kans dat het wordt misbruikt is reeel.
REST API beveiliging en gebruikersenumeratie
De WordPress REST API is krachtig en flexibel, maar standaard staat er meer open dan noodzakelijk. Het meest problematische endpoint is /wp-json/wp/v2/users. Dit endpoint geeft standaard een lijst van alle gebruikers op de website, inclusief hun gebruikersnamen. Een aanvaller hoeft niet te raden welke gebruikersnaam de admin heeft. Die vraagt het gewoon op via de REST API.
Hetzelfde geldt voor de oudere ?author=N methode. Door ?author=1, ?author=2, etc. aan te roepen, kan een aanvaller alle gebruikersnamen achterhalen via de doorverwijzing naar het auteurarchief.
Beide methoden moeten geblokkeerd worden. Blokkeer de REST API users endpoint voor niet geauthenticeerde gebruikers. Blokkeer author archives of retourneer een 404. En overweeg om de REST API volledig te beperken tot geauthenticeerde gebruikers als je geen publieke API nodig hebt (de meeste WordPress websites hebben dat niet).
Tweefactorauthenticatie (2FA)
Tweefactorauthenticatie voegt een tweede verificatiestap toe aan het inlogproces. Naast je wachtwoord heb je een tijdelijke code nodig die wordt gegenereerd door een authenticator app op je telefoon (TOTP), via e-mail wordt verstuurd of uit een lijst van eenmalige backup codes komt. Zelfs als een aanvaller je wachtwoord weet (via een datalek, brute force of social engineering), kan die niet inloggen zonder de tweede factor.
Dit is een van de effectiefste beveiligingsmaatregelen die er bestaan en tegelijkertijd een van de eenvoudigst te implementeren. Kies een plugin die TOTP (authenticator app), e-mail codes en backup codes ondersteunt, afdwingbaar per gebruikersrol. Let op dat de 2FA implementatie alleen de interactieve login uitdaagt en niet de REST API, WP-CLI of cron authenticatie breekt.
Login pagina beveiligen
De standaard WordPress login pagina is bereikbaar op /wp-login.php en /wp-admin. Elke bot op het internet weet dit en richt daar geautomatiseerde brute force aanvallen op. Er zijn meerdere maatregelen die je kunt combineren:
- Custom login URL — verplaats de login pagina naar een aangepaste URL die alleen jij kent. De standaard URL's retourneren dan een 404. Dit stopt het overgrote deel van de geautomatiseerde aanvallen.
- Brute force bescherming — blokkeer IP adressen na een bepaald aantal mislukte inlogpogingen, met escalerende blokkadeduur (eerst een uur, dan zes uur, dan een dag, dan een week). Effectief tegen vasthoudende aanvallers.
- Alleen inloggen met e-mailadres — sta inloggen alleen toe met een e-mailadres, niet met een gebruikersnaam. Dit maakt gebruikersenumeratie nutteloos omdat een aanvaller het e-mailadres moet raden, niet alleen de gebruikersnaam.
Versieinformatie verbergen
WordPress voegt standaard een meta tag toe aan de broncode met het versienummer: <meta name="generator" content="WordPress 6.x" />. Het voegt ook versienummers toe aan CSS en JavaScript bestanden. En het bestand /readme.html is standaard toegankelijk en toont de WordPress versie.
Deze informatie helpt een aanvaller om te bepalen welke kwetsbaarheden van toepassing zijn op jouw specifieke versie. Verwijder de generator meta tag, verwijder versienummers uit asset URLs, blokkeer toegang tot readme.html en license.txt. Het is security through obscurity: het stopt geen gerichte aanval, maar het maakt geautomatiseerde scans minder effectief.
PHP uitvoering blokkeren in upload directories
De wp-content/uploads directory is een van de favoriete plekken voor aanvallers om malware te verstoppen. Ze uploaden een PHP bestand vermomd als afbeelding en voeren het vervolgens uit door het direct aan te roepen in de browser. Dit is eenvoudig te voorkomen door PHP uitvoering te blokkeren in de uploads directory (en andere directories waar alleen statische bestanden horen te staan). Op Apache/LiteSpeed doe je dit met een .htaccess regel, op Nginx met een location block.
Application Passwords uitschakelen
Sinds WordPress 5.6 kunnen gebruikers application passwords aanmaken: unieke wachtwoorden voor externe applicaties die via de REST API met WordPress communiceren. Als je geen externe applicaties gebruikt die via de REST API inloggen, schakel application passwords dan uit. Het is een extra authenticatie oppervlak dat je niet nodig hebt.
Admin creatie alerts
Een veelgebruikte techniek bij gehackte WordPress websites is het aanmaken van een nieuw admin account of het promoveren van een bestaand account naar admin rechten. Dit gebeurt vaak stilletjes via de database of via een backdoor in een plugin bestand. Door een alert in te stellen die je onmiddellijk e-mailt wanneer er een administrator account wordt aangemaakt of wanneer een gebruiker wordt gepromoveerd naar admin, detecteer je deze tactiek direct.
Hoe veilig is jouw WordPress website?
Onze scanner controleert je website op beveiligingsheaders, plugin kwetsbaarheden, openstaande gevoelige bestanden, publieke gebruikersnamen, verouderde software en meer. De resultaten zijn vaak een eye-opener.
Het probleem met Wordfence, Kadence Security en co.
Voordat we onze eigen oplossing presenteren, moeten we eerlijk zijn over wat de populaire beveiligingsplugins werkelijk doen — en niet doen.
Ze beveiligen niet wat het belangrijkst is
Wordfence, Kadence Security (voorheen Solid Security, daarvoor iThemes Security, daarvoor Better WP Security — vier keer hernoemd, zelfde product), Sucuri, All In One Security — ze delen allemaal dezelfde fundamentele beperking. Ze draaien binnen WordPress. Ze kunnen pas iets doen nadat PHP is geladen, WordPress is opgestart en de plugin zelf is geinitialiseerd. Op dat punt is een aanvaller die de server, PHP of de webserver als vector gebruikt al lang voorbij de "beveiliging" van de plugin.
Als je server geen website isolatie heeft (CloudLinux), geen WAF op serverniveau draait, een verouderde PHP versie gebruikt of geen HTTP beveiligingsheaders stuurt, verandert Wordfence daar niets aan. De plugin ziet die lagen niet eens. Het is alsof je een inbraakalarm installeert in een huis zonder muren.
De bloat die ze toevoegen
Dit is wat de meeste gebruikers niet beseffen: beveiligingsplugins zijn zelf een beveiligingsrisico. We hebben de broncode van alle drie de plugins gedownload en vergeleken. De cijfers spreken voor zich:
- Kadence Security Pro (iThemes/Solid): 126.182 regels eigen PHP code, 1.127 PHP bestanden, 8,6 MB download. Niet los verkrijgbaar — alleen als onderdeel van de Kadence Pro bundel voor $299 per jaar (unlimited sites).
- Wordfence: 75.380 regels eigen PHP code, 450 PHP bestanden, 8,1 MB download. $149 per jaar, per site. Vijf websites? $745 per jaar. De Pro versie bevat exact dezelfde codebase als de gratis versie — het verschil is 8 regels code. Je betaalt $149 om feature flags te ontgrendelen in code die al op je server draait.
- Zamok: 21.782 regels eigen PHP code, 416 PHP bestanden, 934 KB download. Gratis, voor altijd.
Zamok bevat bijna 6x minder code dan Kadence Security en 3,5x minder dan Wordfence — en doet meer, omdat het naast beveiliging ook SMTP e-mail, versleutelde backups, afbeelding optimalisatie, database tools en content duplicatie biedt. Elke regel code die je niet draait is een regel die niet kwetsbaar kan zijn, geen geheugen verbruikt en je website niet vertraagt.
Kadence Security heeft in zijn bestaan meerdere keren zijn eigen kwetsbaarheden geintroduceerd. Een beveiligingsplugin met beveiligingslekken — de ironie is pijnlijk maar het is de onvermijdelijke realiteit van een codebase van 126.000 regels die draait binnen WordPress.
Het verdienmodel: angst verkoopt
De gratis versies van deze plugins zijn ontworpen om je bang te maken. Rode waarschuwingen in je dashboard. "Kritieke beveiligingsproblemen gevonden!" Oplossing? Upgrade naar Premium.
- Wordfence Premium: $149 per jaar, per site. Heb je 5 websites? Dat is $745 per jaar. Voor een plugin die op serverniveau niets kan doen.
- Kadence Security (voorheen Solid Security, daarvoor iThemes Security, daarvoor Better WP Security): niet los te koop, alleen als onderdeel van de Kadence Pro bundel voor $299 per jaar (unlimited sites). Een plugin die vier keer van naam is veranderd en nu eigendom is van Liquid Web/Newfold Digital (USA).
- Sucuri: verkoopt naast de plugin hun eigen WAF/CDN dienst. De plugin is gratis, maar de daadwerkelijke bescherming zit achter een betaald abonnement.
En wat krijg je voor die $149 of $299 per jaar? Features die op een goed beveiligde server overbodig zijn: een firewall die je WAF al doet, malware scanning die Imunify360 al doet, brute force bescherming die je server al biedt. Je betaalt voor een duplicatie van beveiligingslagen die op serverniveau beter en sneller werken.
Daarbovenop verzamelen ze data. Wordfence stuurt "anonieme" gebruiksstatistieken. Kadence Security belt naar huis voor licentievalidatie. Sucuri wil dat je hun CDN/WAF dienst koopt. Het zijn bedrijven die geld verdienen aan de angst voor hacks — niet aan het daadwerkelijk beveiligen van je website.
Zamok: onze oplossing
Daar hebben we iets aan gedaan. We hebben Zamok gebouwd: onze eigen open-source WordPress beveiligingsplugin, gratis beschikbaar op wordpress.org. Zamok (Замок — betekent zowel kasteel als slot in het Oekraiens) is 100% gratis, heeft geen betaalde versie, verzamelt geen data en bevat geen tracking of telemetrie.
Zamok probeert niet je server te zijn. Het doet wat een WordPress plugin wel goed kan doen: WordPress zelf hardenen, het aanvalsoppervlak minimaliseren, authenticatie versterken en je admin ervaring verbeteren. Daarnaast vervangt het een hele stapel losse plugins — voor SMTP, backups, afbeelding optimalisatie, database tools en meer — waardoor je minder code draait, minder potentiele kwetsbaarheden hebt en je website sneller laadt.
Wat Zamok doet
Zamok is volledig modulair. Elke functie is een aparte module die je aan of uit kunt zetten vanaf een overzichtelijke admin pagina. Je gebruikt alleen wat je nodig hebt, de rest staat uit en verbruikt geen resources. De beveiligingsmodules:
- Tweefactorauthenticatie — TOTP authenticator app, e-mail codes of eenmalige backup codes. Afdwingbaar per gebruikersrol. Volledig self-hosted, geen externe diensten.
- Brute force bescherming — blokkeert IP adressen na herhaalde mislukte inlogpogingen met escalerende blokkadeduur: 1 uur, 6 uur, 24 uur, 1 week.
- IP banning — automatische banning van kwaadaardige IP adressen met escalerende duur (tot 7 dagen), handmatige bans, een allowlist en een volledige ban log. Geen permanente bans: alles verloopt en wordt automatisch opgeruimd.
- System hardening — server en bestandssysteem hardening via .htaccess: bescherming van systeembestanden, uitschakelen van directory browsing, blokkeren van PHP uitvoering in beschrijfbare directories.
- Gebruikersenumeratie blokkeren — blokkeert
?author=Nen beperkt het REST API users endpoint. - Admin creatie alerts — stuurt onmiddellijk een e-mail wanneer er een administrator account wordt aangemaakt of een gebruiker naar admin wordt gepromoveerd.
Debloat: minder code, minder aanvalsoppervlak
Naast beveiliging biedt Zamok uitgebreide debloat modules. Elke WordPress functie die je uitschakelt is code die niet meer draait, een endpoint dat niet meer bereikbaar is en een aanvalsoppervlak dat verdwijnt:
- XML-RPC uitschakelen — inclusief de X-Pingback header en pingbacks.
- REST API beperken — blokkeert REST toegang voor niet geauthenticeerde gebruikers.
- Application Passwords uitschakelen — sluit dit authenticatie oppervlak.
- Auteurarchief uitschakelen — retourneert 404, voorkomt enumeratie.
- Bestandseditor uitschakelen — de Theme/Plugin File Editor en de Site Editor.
- Kleinere componenten verwijderen — versie informatie, legacy meta tags, emoji scripts, frontend Dashicons, jQuery Migrate.
- Custom login URL — verplaatst de login pagina naar een aangepaste URL.
- Alleen e-mail login — beperkt inloggen tot e-mailadressen.
- Feeds uitschakelen — schakelt RSS, Atom en RDF feeds uit.
- Heartbeat control — schakelt de WordPress Heartbeat uit op de frontend en vertraagt het in de admin.
- Comments uitschakelen — schakelt het complete reactiesysteem uit, bestaande reacties blijven bewaard.
- Embeds uitschakelen — schakelt oEmbed auto-discovery en het embed script uit.
- Gravatars uitschakelen — stopt externe verzoeken naar gravatar.com.
- Strip Comment Author IP (AVG) — stopt het opslaan van IP adressen van reageerders.
Tools en utilities
Zamok vervangt ook een hele reeks losse plugins voor dagelijks beheer:
- SMTP e-mail — SMTP bezorging, geforceerd From adres en een volledige bezorglog met weergave, opnieuw verzenden en automatisch opschonen.
- Afbeelding optimalisatie — automatische conversie naar WebP met native WordPress beeldverwerking.
- Versleutelde backups — volledige site backup (bestanden + database) als versleuteld pakket met libsodium. Werkt op shared hosting, met optionele planning en SFTP push. Inclusief een standalone restore installer.
- Database tools — serialisatie veilige zoek en vervang, database opschonen (revisies, prullenbak, spam, verlopen transients, orphaned meta).
- Content duplicatie — pagina's, berichten, custom post types en taxonomie termen dupliceren met alle custom fields en ACF velden.
- SVG upload — SVG uploads met automatische sanitisatie.
- Media vervanging — vervang een mediabestand met behoud van dezelfde ID en bestandsnaam.
Op basis van geautomatiseerde benchmarks verlaagt Zamok admin laadtijden met 40-50%, database queries met 65-80% en geheugengebruik met 35-50% ten opzichte van de plugins die het vervangt.
Zamok vs Wordfence vs Kadence Security: de vergelijking
We hebben de broncode van alle drie de plugins gedownload en vergeleken. Hieronder staan de feiten.
Zamok bevat 3,5x minder code dan Wordfence en bijna 6x minder dan Kadence Security — en biedt meer functionaliteit. Het verschil: Zamok probeert niet je server te zijn. Het doet wat een WordPress plugin goed kan doen (hardening, authenticatie, debloat, tools) en laat de serverlaag over aan je server. Wordfence en Kadence proberen alles: firewall, scanner, hardening, monitoring. Het resultaat is een opgeblazen codebase die je website vertraagt en zelf een aanvalsoppervlak vormt.
De complete WordPress hardening checklist
Hieronder staat een volledige checklist van alle beveiligingsmaatregelen die we in dit artikel hebben behandeld, gegroepeerd per laag. Gebruik deze lijst om je eigen WordPress website systematisch te controleren en te beveiligen.
Server en infrastructuur
- Website isolatie (CloudLinux CageFS of vergelijkbaar)
- Web Application Firewall (WAF) op serverniveau
- Imunify360 of vergelijkbare server beveiligingssuite
- PHP op de meest recente stabiele versie
- Dagelijkse backups met minimaal 30 dagen retentie
- Backups op gescheiden opslag
- Brute force bescherming op serverniveau (niet alleen WordPress)
- Malware scanning op serverniveau
- File integrity monitoring
- SSL certificaat (HTTPS)
HTTP headers
- Content-Security-Policy met restrictief beleid
- Strict-Transport-Security met max-age van minimaal een jaar
- X-Content-Type-Options: nosniff
- X-Frame-Options: SAMEORIGIN
- Referrer-Policy: strict-origin-when-cross-origin
- Permissions-Policy: camera, microfoon, locatie en FLoC geblokkeerd
WordPress configuratie
- wp-config.php niet toegankelijk via de browser
- DISALLOW_FILE_EDIT en DISALLOW_FILE_MODS ingeschakeld
- WP_DEBUG uitgeschakeld in productie
- Unieke authentication keys en salts
- Aangepast database prefix (niet wp_)
- Database gebruiker met minimale rechten
- Bestandspermissies: directories 755, bestanden 644, wp-config.php 600
Aanvalsoppervlak minimaliseren
- XML-RPC volledig uitgeschakeld
- REST API beperkt voor niet geauthenticeerde gebruikers
- REST API users endpoint geblokkeerd
- Auteurarchief uitgeschakeld of 404
- Application passwords uitgeschakeld
- Versie informatie verwijderd (meta tag, asset URLs, readme.html)
- PHP uitvoering geblokkeerd in wp-content/uploads
- Directory listing uitgeschakeld
- Ongebruikte plugins en themes verwijderd
Authenticatie en toegang
- Tweefactorauthenticatie voor alle admin accounts
- Custom login URL (niet /wp-login.php)
- Brute force bescherming met escalerende blokkade
- Gebruikersenumeratie geblokkeerd (?author=N en REST API)
- Sterke, unieke wachtwoorden voor elk account
- Standaard "admin" account verwijderd of hernoemd
- Admin creatie alerts
- Alleen e-mail login (optioneel)
Onderhoud
- WordPress core, plugins en themes altijd up-to-date
- PHP op de meest recente versie
- Minimaal aantal plugins
- Continue monitoring op bestandswijzigingen
- Regelmatige security scans
Wachtwoorden: het menselijke beveiligingslek
Alle technische maatregelen in de wereld helpen niet als het wachtwoord van je admin account "Welkom2024!" is. Of als je hetzelfde wachtwoord gebruikt voor je WordPress admin, je e-mail, je hostingpanel en je bankrekening. Wachtwoorden zijn het punt waar technische beveiliging en menselijk gedrag samenkomen en waar het in de praktijk het vaakst misgaat.
Credential stuffing: waarom hergebruikte wachtwoorden gevaarlijk zijn
Credential stuffing is een aanval waarbij gelekte wachtwoorden van de ene dienst worden geprobeerd op andere diensten. Er zijn miljarden gebruikersnaam/wachtwoord combinaties gelekt via datalekken bij bedrijven als LinkedIn, Adobe, Dropbox en talloze andere diensten. Die gelekte combinaties worden gebundeld in databases die criminelen kopen en verkopen.
Een aanvaller hoeft niet te raden. Die pakt je e-mailadres uit een gelekt LinkedIn database, het wachtwoord dat daarbij hoort, en probeert dezelfde combinatie op je WordPress admin, je e-mail, je hostingpanel. Als je hetzelfde wachtwoord hergebruikt, is de aanvaller binnen zonder enige technische exploit. Zonder brute force. Zonder kwetsbare plugin. Gewoon inloggen met je eigen wachtwoord.
Dit is geen hypothetisch scenario. Het is een van de meest voorkomende manieren waarop websites worden gecompromitteerd. En het is volledig te voorkomen door voor elke dienst een uniek wachtwoord te gebruiken. Lees ons artikel over wachtwoorden en datalekken om te controleren of jouw gegevens al zijn gelekt.
Wachtwoordmanagers: de enige praktische oplossing
Een sterk, uniek wachtwoord voor elke dienst onthouden is onmogelijk. Daarom zijn wachtwoordmanagers essentieel. Een wachtwoordmanager genereert lange, willekeurige wachtwoorden voor elke dienst en slaat ze versleuteld op. Je onthoudt een master wachtwoord, de manager regelt de rest.
Het maakt niet zoveel uit welke wachtwoordmanager je kiest, zolang je er een gebruikt. Het verschil tussen "een wachtwoordmanager gebruiken" en "geen wachtwoordmanager gebruiken" is vele malen groter dan het verschil tussen de ene en de andere manager.
Twee factor als vangnet
Tweefactorauthenticatie is het vangnet voor wanneer je wachtwoord toch compromised raakt. Zelfs als een aanvaller je wachtwoord kent uit een datalek, kan die niet inloggen zonder de tweede factor. Combineer sterke, unieke wachtwoorden met 2FA en credential stuffing wordt praktisch onmogelijk. Dit geldt niet alleen voor WordPress maar voor elke dienst die 2FA ondersteunt.
Managed hosting: waarom beveiliging uitbesteden logisch is
Alle maatregelen in dit artikel zijn technisch implementeerbaar door iemand met de juiste kennis. Maar laten we eerlijk zijn: de meeste website eigenaren zijn geen systeembeheerders. Ze zijn ondernemers, marketeers, winkeliers. Ze willen een website die werkt, veilig is en goed presteert, zonder dat ze zelf iptables regels moeten schrijven of CSP headers moeten configureren.
Dat is precies waar managed hosting voor is. Bij managed hosting beheren wij de complete server omgeving, inclusief alle beveiligingsmaatregelen die we in dit artikel behandelen. De website eigenaar hoeft zich nergens zorgen over. Wij configureren de server beveiliging (CloudLinux, Imunify360, WAF). Wij implementeren de HTTP headers (CSP, HSTS, alle beveiligingsheaders). Wij harden de WordPress installatie. Wij updaten WordPress, plugins en PHP. Wij monitoren op malware en indringers. Wij maken dagelijkse backups. En als er toch iets misgaat, lossen wij het op.
Wat onze managed hosting omvat op het gebied van beveiliging
- CloudLinux isolatie — elke website in een eigen geisoleerde omgeving.
- Imunify360 — realtime malware scanning, WAF, proactieve verdediging, brute force bescherming.
- LiteSpeed webserver — sneller dan Apache en Nginx, met ingebouwde beveiligingsfuncties.
- Dagelijkse backups — 30 dagen retentie, op gescheiden opslag.
- SSL certificaat — Let's Encrypt, automatisch vernieuwd.
- WordPress updates — core, plugins en themes, getest voordat ze worden doorgevoerd.
- PHP updates — altijd de meest recente stabiele versie.
- HTTP beveiligingsheaders — CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.
- Proactieve monitoring — 24/7 uptime monitoring, bestandswijziging detectie, verdacht verkeer analyse.
- Persoonlijke support — altijd dezelfde developer, geen ticketsysteem.
In 21+ jaar hosting hebben we nog nooit een klant gehad wiens website op onze servers is gehackt. Niet omdat het onmogelijk is (geen enkel systeem is 100% veilig), maar omdat we het maximaal moeilijk maken en alles proactief monitoren.
Bekijk onze managed hosting, lees meer over onze WordPress beveiliging aanpak, onze Europese hosting of neem contact op voor een persoonlijk gesprek over de beveiliging van jouw website.
Wat de meeste webbureaus overslaan
We scannen regelmatig websites van andere webbureaus en hun klanten met onze scanner. De resultaten zijn consistent: vrijwel geen enkel bureau implementeert alle beveiligingslagen die we in dit artikel beschrijven. Dit zijn de meest voorkomende hiaten:
Geen HTTP beveiligingsheaders
De overgrote meerderheid van WordPress websites die wij scannen heeft geen Content Security Policy, geen HSTS, geen X-Content-Type-Options, geen Referrer-Policy en geen Permissions-Policy. Soms staat er een enkele header, maar een volledig set is uiterst zeldzaam. Dit betekent dat de bezoekers van die websites niet beschermd zijn tegen XSS, clickjacking, MIME sniffing en SSL stripping aanvallen.
Plugin kwetsbaarheden als standaard
Net opgeleverde websites met bekende CVE's in plugins. Dit betekent dat het bureau standaard verouderde plugin versies installeert en na oplevering geen updates uitvoert. Elke klant die zo'n website ontvangt is vanaf dag een kwetsbaar voor bekende exploits.
Publiek toegankelijke gevoelige bestanden
WordPress readme.html en license.txt zichtbaar (versie informatie). wp-config.php backup bestanden in de webroot. Soms phpMyAdmin panels op subdomeinen, publiek toegankelijk, met database credentials die in wp-config.php staan. Dit zijn geen exotische problemen. Dit zijn basale beveiligingsfouten die met een paar regels server configuratie te voorkomen zijn.
Gebruikersenumeratie wijd open
Admin gebruikersnamen opvraagbaar via de REST API of via ?author=N. Gecombineerd met het ontbreken van brute force bescherming en 2FA maakt dit wachtwoordaanvallen triviaal.
Geen website isolatie
Veel budgethostingpartijen draaien honderden websites op dezelfde server zonder isolatie. Als een van die websites gehackt wordt, zijn potentieel alle andere websites ook kwetsbaar. Je website deelt letterlijk een server met de zwakst beveiligde site op die machine.
De rode draad in al deze bevindingen: het ontbreekt niet aan kennis die beschikbaar is. Het ontbreekt aan prioriteit. Beveiliging levert geen zichtbaar resultaat op. Een mooie homepage verkoopt. Een goed geconfigureerde Content Security Policy niet. Maar als het misgaat (en bij genoeg tijd gaat het altijd mis), is de schade vele malen groter dan de investering in goede beveiliging. Reputatieschade, dataverlies, AVG boetes, downtime, klanten die het vertrouwen verliezen.
Veelgestelde vragen over WordPress beveiliging.
WordPress beveiliging
op elk niveau.
Van server configuratie tot HTTP headers tot WordPress hardening: wij implementeren alle beveiligingslagen die in dit artikel beschreven staan. Al 21+ jaar, voor elke klant. Bel ons voor een gesprek over de beveiliging van jouw website, of scan je website hieronder.