“Is WordPress wel veilig?” Die vraag krijgen we geregeld. Logisch: WordPress draait op een enorm deel van het web en is daarmee een aantrekkelijk doelwit. Wie de nieuwsberichten over gehackte sites leest, krijgt al snel het idee dat het platform zelf lek is.
In de praktijk zit het probleem zelden in WordPress zelf. Het zit in hoe een site is opgebouwd, welke plugins erop staan, hoe updates binnenkomen en waar de site draait. Dat zijn allemaal keuzes. En keuzes kun je beter maken.
In deze blog lees je welke keuzes wij bij Studio Lemon maken, en waarom.
1. Begin bij het fundament: Bedrock
Een standaard WordPress-installatie zet alles in één map: core, plugins, uploads en het configuratiebestand met je databasewachtwoord. Werkt prima, maar het is niet gebouwd met veiligheid als uitgangspunt.
Daarom starten wij elke build met Bedrock van Roots. Bedrock is een WordPress-boilerplate die een paar dingen anders aanpakt:
- Configuratie buiten de webroot. Gevoelige gegevens staan in een
.env-bestand dat niet via de browser bereikbaar is. - Afhankelijkheden via Composer. WordPress core en plugins zijn vastgelegd met een versienummer. Je weet precies wat er op de site staat.
- Geen bestanden aanpassen via het dashboard. Code bewerken of plugins installeren vanuit wp-admin staat standaard uit. Een gekaapt beheerdersaccount kan dus niet zomaar code toevoegen.
Dat laatste klinkt misschien onhandig. Dat is het ook, en dat is precies de bedoeling. Code komt via een gecontroleerd proces op de server, niet via een knop in het dashboard.
2. Een wachtwoord is niet genoeg
Wachtwoorden lekken. Via een datalek bij een andere dienst, via phishing of omdat iemand hetzelfde wachtwoord overal gebruikt. Met alleen een wachtwoord ligt je beheeromgeving dan open.
Tweestapsverificatie (2FA) lost dat grotendeels op. Naast je wachtwoord heb je een tweede factor nodig, zoals een code uit een authenticator-app of een passkey. Een gelekt wachtwoord alleen is dan niet meer genoeg om binnen te komen.
Het is de goedkoopste maatregel met het meeste effect. Voor ons is 2FA daarom geen extra optie, maar de standaard voor iedereen die kan inloggen.
Voor die 2FA gebruikten we Wordfence Login Security. Toen die plugin niet meer werd onderhouden, stonden we voor een keuze: overstappen op iets nieuws, of het zelf oppakken. We kozen voor het laatste. We hebben de plugin geforkt en volledig gemoderniseerd tot 2FA Login Security:
- Terug naar de kern. Alles wat niet met 2FA te maken heeft, is eruit, zoals de WooCommerce-integratie, reCAPTCHA en de koppeling met de rest van Wordfence. Minder code betekent minder om aan te vallen.
- Een moderne basis. De plugin vraagt nu minimaal PHP 8.1 en WordPress 6.0.
- Wat je nodig hebt, en niet meer. Codes via een authenticator-app (TOTP), eenmalige herstelcodes, 2FA verplicht per gebruikersrol en ondersteuning voor multisite.
De code is open source en voor iedereen te gebruiken. Zo blijft een basismaatregel als 2FA niet afhankelijk van een leverancier die er zomaar mee kan stoppen.
3. Minder plugins, betere plugins
Zo kijken wij ernaar: elke plugin is code van iemand anders die met volledige toegang op jouw site draait. Hoe meer plugins, hoe groter het aanvalsoppervlak. En de kwaliteit verschilt enorm.
We zijn daarom kieskeurig. Veel functionaliteit bouwen we liever zelf in ons framework wp-lemon, dan dat we er een plugin voor installeren. En als een plugin wel nodig is, scannen we die soms zelf op bouwkwaliteit. Waar we dan op letten:
- Onderhoud. Wordt de plugin actief bijgewerkt en reageert de ontwikkelaar op meldingen?
- Omgang met invoer. Wordt alles wat een bezoeker invult netjes gecontroleerd en geschoond?
- Rechten. Vraagt de plugin niet meer toegang dan hij nodig heeft?
- Geschiedenis. Hoe vaak zijn er kwetsbaarheden gevonden, en hoe snel zijn die opgelost?
Een populaire plugin is niet automatisch een goede plugin. Een plugin die je niet installeert, kan ook niet lekken.
4. Updaten zonder blind te vertrouwen
Het standaardadvies is: update alles, en het liefst automatisch. Niet updaten is inderdaad gevaarlijk, want bekende lekken blijven dan open. Maar alles blind automatisch binnenhalen heeft ook een keerzijde. Een update is namelijk gewoon code van iemand anders.
Dat werd deze zomer pijnlijk duidelijk. Op 31 juli 2026 kregen klanten van WPManageNinja vijf uur lang een gemanipuleerde versie van Fluent Forms Pro (6.2.7) en Ninja Tables Pro aangeboden via de officiële updatekanalen. Aanvallers hadden een vergeten server van een oude licentieomgeving overgenomen, waar het updateverkeer nog naartoe liep. De gemanipuleerde versie bevatte een achterdeur: verborgen beheerdersaccounts, extra PHP-bestanden in mu-plugins en uploads, en geplande taken die bleven draaien als je de plugin verwijderde. Er werden 1.368 klanten gewaarschuwd (The Repository, VulnCheck).
Dit heet een supply chain attack: je wordt niet zelf aangevallen, maar via een leverancier die je vertrouwt. Wie automatische updates aan had staan, haalde de achterdeur zelf binnen.
WPManageNinja heeft daarna stevige maatregelen genomen. Updates van Fluent Forms Pro zijn vanaf versie 6.2.13 cryptografisch ondertekend. Een site accepteert alleen nog een update die aantoonbaar door de makers zelf is gebouwd. Netjes opgepakt.
Zo doen wij het
- Twee keer per maand updaten we alles, op serverniveau én op websiteniveau.
- Geen updates die buiten ons om binnenkomen. Door Bedrock en Composer weten we precies welke versie waar staat, en kunnen we snel terug als er iets mis is.
- Kwetsbaarheden worden proactief gemeld en we handelen ze per geval af. Is het urgent, dan wachten we niet op de volgende updateronde.
Zo combineer je regelmaat met controle. Niet updaten is geen optie. Blind updaten ook niet.
5. Je site is zo veilig als je server
Je kunt de netste WordPress-installatie bouwen. Draait die op een verouderde of slecht ingerichte server, dan staat de voordeur alsnog open. Een paar basisvragen om aan je hostingpartij te stellen:
- Draait mijn site op een actuele PHP-versie? Oude versies krijgen geen beveiligingsupdates meer.
- Is mijn site afgeschermd van andere sites op dezelfde server? Anders kan een lek bij de buren ook jouw probleem worden.
- Hoe zijn de toegangsrechten geregeld? Alleen wie het nodig heeft, krijgt toegang, en de webserver mag niet overal schrijven.
- Waar staan de backups? Een backup op dezelfde server als je site helpt je niet als die server wordt overgenomen.
- Wie houdt de boel in de gaten? Monitoring laat je weten dat er iets mis is, voordat je bezoekers het merken.
Bij hosting gaat het niet om de goedkoopste prijs per maand. Het gaat erom wie er verantwoordelijk is als het misgaat.
Veiligheid is geen plugin
Een beveiligingsplugin installeren en klaar: zo werkt het helaas niet. Veiligheid is een optelsom van keuzes. Een solide fundament, goed afgeschermde accounts, een kleine en kritisch gekozen set plugins, een doordacht updatebeleid en een server die op orde is.
Geen van die keuzes is ingewikkeld. Maar je moet ze wel bewust maken, en blijven maken.
Benieuwd hoe jouw WordPress-site
ervoor staat?
We kijken samen waar de risico’s zitten en wat je eraan kunt doen.
