De kern: WordPress-hardening is geen enkele fix maar een gelaagde checklist die toegangscontrole, softwarehygiëne, serverconfiguratie, netwerkbescherming en doorlopende monitoring omvat — elke laag sluit een andere risicocategorie af, en het overslaan van één laag laat een gat achter dat de andere niet dekken.
Waarom een checklist, geen enkele fix
De specifieke kwetsbaarheden die WordPress-sites daadwerkelijk in gevaar brengen — verouderde plugins, zwakke inloggegevens, SQL-injectie, XSS, XML-RPC-misbruik — behandelden we in onze gids over veelvoorkomende WordPress-kwetsbaarheden. Hardening is het proactieve tegenhanger: een gestructureerde set configuratiekeuzes die het aanvalsoppervlak verkleint voordat een specifieke kwetsbaarheid überhaupt in het spel komt, hier per laag geordend zodat niets wordt gemist.
Toegangscontrole harden
- Dwing tweefactorauthenticatie af voor elk account met publicatie- of adminrechten, niet alleen de primaire beheerder.
- Pas least-privilege rollen toe — geef elke gebruiker (en elke klant, als de site door een bureau wordt beheerd) de laagste WordPress-rol die hun daadwerkelijke werk mogelijk maakt, in plaats van iedereen standaard Beheerder te maken.
- Verwijder ongebruikte accounts direct wanneer een teamlid of klantrelatie eindigt, in plaats van een slapend account met blijvende toegang achter te laten.
- Beperk inlogpogingen om geautomatiseerde brute-force-tools die zich richten op wp-login.php te vertragen.
- Hernoem of beperk de standaard "admin"-gebruikersnaam als deze nog wordt gebruikt, aangezien dit de eerste gebruikersnaam is die geautomatiseerde aanvallen proberen.
Kern-, plugin- en themahygiëne
- Schakel automatische updates in voor WordPress-kern, plugins en thema's overal waar de update een laag regressierisico heeft, en test de rest op een staging-kopie voordat je naar productie gaat.
- Audit geïnstalleerde plugins elk kwartaal, verwijder alles wat niet actief wordt gebruikt — een inactieve plugin met een bekende kwetsbaarheid kan in sommige aanvalsketens nog steeds worden misbruikt, ook als deze gedeactiveerd is.
- Controleer de kwetsbaarheidsgeschiedenis en onderhoudsactiviteit van een plugin voordat je deze installeert, en geef de voorkeur aan actief onderhouden plugins met een schone openbaarmakingsgeschiedenis boven verlaten plugins.
Server- en bestandsniveau hardening
- Stel bestandsrechten in op 644 voor bestanden en 755 voor mappen, volgens WordPress' eigen hardeningsdocumentatie, waarbij wp-config.php idealiter nog verder wordt afgesloten omdat het direct databasegegevens bevat.
- Schakel bestandsbewerking vanuit wp-admin uit door define('DISALLOW_FILE_EDIT', true); toe te voegen aan wp-config.php, wat de ingebouwde thema-/plugineditor verwijdert die een aanvaller met adminrechten een directe weg naar het uitvoeren van code geeft.
- Schakel directorybrowsing uit op de server zodat een verkeerd geconfigureerde map geen ruwe bestandslijst blootstelt aan iedereen die deze rechtstreeks opvraagt.
- Wijzig het standaard databasetabelvoorvoegsel (wp_) tijdens de installatie of via een migratietool, waardoor een aanname wordt weggenomen waarop sommige geautomatiseerde SQL-injectiepogingen vertrouwen.
- Schakel XML-RPC uit, tenzij een specifieke plugin (meestal Jetpack) of app dit actief vereist.
Netwerkniveau bescherming
- Dwing HTTPS sitebreed af, leid alle HTTP-verkeer om, aangezien een onversleutelde verbinding inloggegevens en sessiecookies blootstelt aan iedereen op hetzelfde netwerk.
- Voeg een web application firewall (WAF) toe, via een CDN-niveau service of een beveiligingsplugin, om bekende aanvalspatronen te blokkeren voordat ze WordPress zelf bereiken.
- Stel beveiligingsheaders in — Content-Security-Policy, X-Frame-Options en Strict-Transport-Security — die de meeste CDN's en sommige beveiligingsplugins kunnen toepassen zonder WordPress' eigen code aan te raken.
Monitoring, logging en back-ups
- Schakel bestandsintegriteitsmonitoring in zodat een onverwachte wijziging in een kernbestand of een onbekend bestand dat verschijnt in wp-content een waarschuwing activeert in plaats van ongemerkt te blijven.
- Plan regelmatige malwarescans, met een beveiligingsplugin of een externe scandienst, in plaats van pas te controleren als iets al verdacht lijkt.
- Houd geautomatiseerde, externe back-ups aan op een schema dat past bij hoe vaak de site daadwerkelijk verandert, en test periodiek of een back-up daadwerkelijk herstelt in plaats van dit aan te nemen.
- Abonneer je op een kwetsbaarheden-feed zoals WPScan of Patchstack zodat een nieuw bekendgemaakte pluginkwetsbaarheid binnen uren bekend is, niet pas ontdekt wordt na misbruik.
Volledige checklist in één oogopslag
| Categorie | Belangrijkste acties |
|---|---|
| Toegangscontrole | 2FA, least-privilege rollen, ongebruikte accounts verwijderen, inlogpogingen beperken |
| Softwarehygiëne | Auto-updates, kwartaal-audit van plugins, kwetsbaarheidsgeschiedenis controleren vóór installatie |
| Server-/bestandsconfiguratie | 644/755-rechten, bestandsbewerking uitschakelen, directorybrowsing uitschakelen, tabelvoorvoegsel wijzigen, XML-RPC uitschakelen |
| Netwerkbescherming | HTTPS afdwingen, een WAF toevoegen, beveiligingsheaders instellen |
| Monitoring & back-ups | Bestandsintegriteitsmonitoring, geplande malwarescans, geteste externe back-ups, abonnement op kwetsbaarheden-feed |
De compliance-kant: hardening is niet alleen een beveiligingsextraatje
Voor bureaus en bedrijven die in de EU actief zijn, overlappen hardeningsmaatregelen steeds meer met wettelijke verplichtingen in plaats van pure optionele best practice te zijn. De EU Cyber Resilience Act vereist dat fabrikanten van producten met digitale elementen — wat onder bepaalde voorwaarden ook commerciële WordPress-plugins en -thema's omvat — voldoen aan basisvereisten voor cybersecurity en kwetsbaarheidsopenbaarmaking verantwoord afhandelen gedurende de hele levensduur van een product, niet alleen bij de lancering.
De technische hardeningsstappen hierboven (updates, toegangscontrole, kwetsbaarheidsmonitoring) ondersteunen direct de beveiligingskant van die verplichting, hoewel volledige naleving ook aparte documentatie vereist — een kwetsbaarheidsopenbaarmakingsbeleid, een software bill of materials (SBOM) en conformiteitsrecords — die hardening alleen niet oplevert. Dit is precies het gat dat onze Erdo CRA Compliance-plugin helpt dichten: een site scannen tegen CRA-, AVG- en NIS2-vereisten en de documentatie genereren die een hardeningschecklist alleen niet dekt.
Veelgemaakte hardeningsfouten
- Hardening behandelen als een eenmalige installatietaak in plaats van een terugkerende beoordeling, waardoor gebruikersaccounts en pluginlijsten in de loop van maanden uit een veilige staat afdrijven.
- Een beveiligingsplugin installeren en de checklist als voltooid beschouwen, terwijl bestandsrechten op serverniveau en toegangscontrolebeslissingen nog steeds onafhankelijk moeten worden afgehandeld.
- De live site direct harden voor wijzigingen zoals het uitschakelen van bestandsbewerking of het beperken van rechten, zonder eerst op staging te testen voor het geval een plugin afhankelijk is van de uitgeschakelde functionaliteit.
- Nooit testen of back-ups daadwerkelijk herstellen, waardoor een corrupte of onvolledige back-up pas tijdens een echt incident wordt ontdekt.
- Alle hardeningsstappen toepassen behalve updates, terwijl verouderde software het meest misbruikte toegangspunt blijft, ongeacht hoe gehard al het andere is.
Tot slot
Kortom, WordPress-hardening werkt als een gelaagde checklist in plaats van een enkele actie — toegangscontrole, softwarehygiëne, serverconfiguratie, netwerkbescherming en doorlopende monitoring sluiten elk een andere risicocategorie af, en voor op de EU gerichte sites dienen meerdere van deze stappen nu ook als basis voor wettelijke naleving in plaats van optionele best practice. De volledige lijst elk kwartaal herzien, in plaats van deze eenmalig in te stellen en aan te nemen dat ze standhoudt, is wat een geharde site daadwerkelijk gehard houdt naarmate de tijd verstrijkt.