Een WordPress-site is zo sterk als de zwakste plugin, het zwakste account of de zwakste back-up. De WordPress-core krijgt regelmatig beveiligingsupdates; wat u eraan toevoegt en hoe u de site beheert, is aan u. Deze checklist behandelt de maatregelen die het meest uitmaken, ongeveer in de volgorde waarin wij ze zouden toepassen.
1. Houd core, plugins en thema’s up-to-date
Automatische updates op de achtergrond bestaan voor de core sinds WordPress 3.7, en standaard gelden ze voor kleine releases. Sinds WordPress 5.5 kunt u ook voor elke plugin en elk thema automatische updates inschakelen in het beheerscherm.
- Schakel automatische updates in voor plugins van betrouwbare ontwikkelaars, en beoordeel de rest wekelijks.
- Automatische updates zijn afhankelijk van WP-Cron. Controleer Gereedschap > Sitediagnose (Tools > Site Health) op fouten, want als cron niet werkt, stoppen updates zonder melding.
- Zorg dat u een update kunt terugdraaien voordat u op automatische updates vertrouwt. De WordPress-documentatie raadt hetzelfde aan.
2. Verwijder verlaten en ongebruikte plugins
De hardeningsgids van WordPress is duidelijk: houd plugins up-to-date en verwijder de plugins die u niet gebruikt. Deactiveren is niet genoeg, want de code blijft op de server staan.
De plugindirectory van WordPress.org geeft u twee waarschuwingssignalen:
- Een gele melding dat een plugin "niet is getest met de laatste 3 hoofdversies van WordPress".
- Een rode melding dat een plugin is gesloten en niet meer kan worden gedownload. Na 60 dagen wordt de reden getoond, en "beveiligingsprobleem" is een van de mogelijke redenen.
Een gesloten plugin krijgt geen updates meer via WordPress.org. Vervang hem. Installeer nooit "nulled" (illegaal ontgrendelde) kopieën van premiumplugins, en installeer alleen vanuit WordPress.org of van leveranciers die u vertrouwt.
3. Controleer de beheerdersaccounts
Maak een lijst van elk account met de rol Beheerder en verwijder de accounts die niemand kan verklaren. Met WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredGeef iedereen een eigen account op naam, nooit een gedeelde login admin. Gebruik de laagste rol waarmee het werk kan worden gedaan: de meeste redacteuren hebben geen beheerdersrechten nodig. Eis sterke, unieke wachtwoorden, bij voorkeur opgeslagen in een wachtwoordmanager.
4. Schakel tweefactorauthenticatie in
Schakel 2FA in voor elke beheerder. De WordPress-core heeft geen ingebouwde 2FA, dus u hebt een plugin nodig of een single sign-on-provider die 2FA afdwingt. Kies bij voorkeur methoden zoals beveiligingssleutels of passkeys als uw plugin die ondersteunt, en bewaar herstelcodes op een veilige plek.
5. Beperk inlogpogingen en beslis over XML-RPC
De WordPress-documentatie noemt wp-login.php en xmlrpc.php als veelvoorkomende doelwitten van brute-force-aanvallen. Ze raadt aan inlogpogingen te beperken aan de rand van het netwerk (een WAF of CDN) of op de webserver. Een beveiligingsplugin kan inlogpogingen ook afremmen, maar draait in PHP, dus de oplossing op serverniveau houdt beter stand bij veel verkeer.
Gebruikt u XML-RPC niet, schakel het dan uit. Sommige mobiele apps en diensten zoals Jetpack hebben het nodig, dus controleer dat eerst. Let op: het filter xmlrpc_enabled schakelt alleen methoden uit waarvoor authenticatie nodig is. Pingbacks en andere methoden zonder authenticatie blijven werken. Om het volledig uit te schakelen, blokkeert u het bestand op de webserver. Voor nginx:
location = /xmlrpc.php {
deny all;
}6. Schakel de ingebouwde bestandseditor uit
Met de thema- en plugineditor in het dashboard kan iedereen met een beheerderssessie PHP-code wijzigen. Schakel de editor uit in wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );Volgens de documentatie van wp-config.php gaat DISALLOW_FILE_MODS verder en blokkeert het ook het installeren en updaten van plugins en thema’s vanuit het dashboard. Gebruik dit alleen als u wijzigingen op een andere manier uitrolt, bijvoorbeeld via Git of WP-CLI.
7. Bewaar back-ups buiten de server en buiten de webroot
De hardeningsgids raadt regelmatige back-ups aan van zowel bestanden als database, meerdere snapshots en een betrouwbare opslaglocatie. Bescherm de integriteit ervan met versleuteling, vastgelegde hashes of alleen-lezenmedia.
Daaruit volgen twee praktische regels. Een back-up binnen de webroot, zoals een zipbestand in wp-content, kan worden gedownload door iedereen die de naam raadt. Een back-up op dezelfde server kan door dezelfde aanvaller worden verwijderd. Bewaar minstens één kopie op een plek die de inloggegevens van de site niet kunnen bereiken, en test een volledig herstel.
8. Controleer de bestandsintegriteit
WP-CLI kan uw bestanden vergelijken met de officiële checksums van WordPress.org zonder WordPress te laden:
wp core verify-checksums --include-root
wp plugin verify-checksums --allHet eerste commando signaleert gewijzigde corebestanden, en --include-root waarschuwt voor onverwachte bestanden in de hoofdmap. Het tweede vergelijkt plugins met de checksums van WordPress.org en helpt dus alleen voor plugins die daar worden gehost. Zoek ook naar PHP-bestanden in wp-content/uploads, waar normaal alleen media horen te staan.
9. Gebruik een databasegebruiker met minimale rechten
Geef elke site een eigen database en een eigen databasegebruiker, met rechten op alleen die database. Maak nooit verbinding als de rootgebruiker van de database.
De hardeningsgids merkt op dat voor de dagelijkse werking alleen SELECT, INSERT, UPDATE en DELETE nodig zijn. De gids raadt niet aan om DROP, ALTER en GRANT in te trekken, omdat plugins en grote updates het schema soms moeten wijzigen. Trekt u ze toch in, zorg dan voor geteste back-ups.
10. Stel bestandsrechten in
Het vertrekpunt van de gids is 755 voor mappen en 644 voor bestanden. Corebestanden, wp-admin en wp-includes horen alleen schrijfbaar te zijn voor uw eigen gebruikersaccount, niet voor de webserver. wp-content is de uitzondering: de webserver moet daar kunnen schrijven voor uploads. Voor wp-config.php stelt de gids 400 of 440 voor.
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.phpPas de paden en het eigenaarschap aan uw hostingomgeving aan voordat u deze commando’s uitvoert.
11. Verstuur beveiligingsheaders
Headers zoals Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options en Referrer-Policy voegen bescherming aan de kant van de browser toe. Stel ze waar mogelijk in op de webserver of het CDN, in plaats van via een plugin. Begin met een Content Security Policy in report-only-modus, omdat thema’s en pagebuilders mogelijk inline scripts gebruiken.
12. Zet er een WAF voor
De WordPress-documentatie beschrijft drie niveaus: beveiligingsplugins die verzoeken binnen WordPress filteren, een firewall op serverniveau zoals ModSecurity, en reverse-proxydiensten die verkeer filteren voordat het uw server bereikt. Hoe verder naar buiten het filteren gebeurt, hoe minder belasting PHP bereikt. Een WAF vervangt geen updates. Hij geeft u tijd tussen de openbaarmaking van een kwetsbaarheid en uw patch.
De korte versie
| Onderdeel | Minimum |
|---|---|
| Updates | Automatische updates voor kleine core-releases aan, plugins wekelijks beoordeeld |
| Plugins | Geen gesloten, verlaten of ongebruikte plugins geïnstalleerd |
| Accounts | Accounts op naam, weinig beheerders, 2FA voor allemaal |
| Inloggen | Beperking van inlogpogingen op de server of aan de rand, XML-RPC geblokkeerd als het niet wordt gebruikt |
| Codewijzigingen | DISALLOW_FILE_EDIT ingesteld |
| Back-ups | Buiten de server, buiten de webroot, herstel getest |
| Integriteit | Checksums geverifieerd, geen PHP in uploads |
| Database | Eén gebruiker per site, met rechten op alleen de eigen database |
| Browser | HSTS en een geteste CSP |
| Buitengrens | WAF of reverse proxy ervoor |
Waar u begint
Begin met de eerste vier punten. Ze kosten weinig tijd en vergen geen wijziging van uw hosting. Controleer daarna uw huidige headers met onze scanner voor beveiligingsheaders.
Wilt u dit voor u laten controleren? SecAudit scant WordPress op malware en webshells, verifieert de bestandsintegriteit aan de hand van officiële checksums en koppelt geïnstalleerde plugins aan bekende kwetsbaarheden.
