wp-config.php beveiligen: een nuchtere handleiding voor WordPress-eigenaren

wp-config.php beveiligen klinkt als iets voor systeembeheerders, maar het is een avondje werk en levert meer rendement dan de tiende security-plugin die je installeert. In dit artikel loop ik door negen aanpassingen die ik op vrijwel elke WordPress-site uitvoer voordat ik andere lagen optuig. Een gehackte site is vervelend, geen ramp, maar voorkomen is hier echt goedkoper dan herstellen.

Het bestand zelf is een PHP-script, geen geheim kluisje. Wie er bij kan, kan in de database. Wie in de database kan, kan administrator-accounts aanmaken. Dat is het hele verhaal. De maatregelen hieronder leggen er meerdere drempels voor.

Verbeteren boven herbouwen: je hoeft je site niet opnieuw te bouwen om hem veilig te maken.

Wat staat er in wp-config.php en waarom is dit het belangrijkste bestand

wp-config.php zit in de root van je WordPress-installatie en bevat de configuratie die WordPress nodig heeft om te draaien. Concreet:

• De database-naam, gebruikersnaam, het wachtwoord en de host
• De security keys en salts die sessies en cookies versleutelen
• De table-prefix waarmee tabelnamen beginnen
• Eventuele constants die het gedrag van WordPress aanpassen (debug, file-edit, SSL)

Lekt dit bestand, dan heeft een aanvaller direct toegang tot je database. Vanaf daar maakt hij een admin-account aan, of injecteert hij malware in wp_options. De stappen hieronder zijn er allemaal op gericht om dat scenario zoveel mogelijk drempels te geven.

In mijn ervaring proberen mensen te veel in wp-config.php te proppen. Het bestand is voor configuratie, niet voor secrets van externe API’s of voor functionele logica. Dat hoort op andere plekken thuis, daarover later meer.

wp-config.php beveiligen begint bij bestandsrechten en locatie

De eerste laag is de simpelste en wordt het vaakst vergeten: file permissions. Op een typische LAMP-stack ziet de juiste configuratie er zo uit:

• wp-config.php: chmod 440 of 400
• Overige PHP-bestanden in de root: 644
• Directories: 755
• Eigenaar: de webserver-user (vaak www-data of nginx), nooit root

Met chmod 440 kan de webserver-user het bestand lezen, niemand anders. Schrijven naar het bestand gaat dan niet meer, ook niet via FTP. Dat is een feature, geen bug: WordPress hoeft wp-config.php niet zelf te schrijven na de installatie.

Op shared hosting heb je niet altijd controle over de eigenaar. De meeste managed hosters zetten dit standaard goed, maar controleren mag. Een snelle check via SSH:

ls -la wp-config.php

Verschijnt er iets als -rw-rw-rw- (666), dan staat het te ruim open. Bij twijfel kun je naar 440 of 400.

Bestand buiten de webroot. WordPress checkt automatisch de bovenliggende map: zit er een wp-config.php één niveau hoger dan de root, dan wordt die geladen. Verplaats het bestand één niveau omhoog en je hebt een extra laag tussen een willekeurige PHP-fout en je database-credentials. Werkt niet op alle managed hosters (sommige sluiten alles buiten public_html af), dus test eerst op een staging-omgeving.

Security keys en salts: roteren elke 6 tot 12 maanden

Onderaan wp-config.php staat een blok met acht constants: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, en de bijbehorende salts. Deze waarden versleutelen cookies en sessies. Bij een installatie zijn ze door WordPress gegenereerd, en daarna meestal nooit meer aangeraakt.

Roteren is verstandig in twee gevallen: routinematig elke 6 tot 12 maanden, en altijd na een incident. Je genereert nieuwe waarden via de officiele generator van WordPress:

https://api.wordpress.org/secret-key/1.1/salt/

Plak het blok over het bestaande blok heen in wp-config.php. Bewaar de oude waarden niet “voor de zekerheid”: dat is precies de bedoeling niet.

Het gevolg: alle huidige sessies worden ongeldig. Iedere ingelogde gebruiker, jij inclusief, wordt uitgelogd. Geen data-verlies, geen schade, maar wel kort op alle kanalen even iedereen opnieuw laten inloggen. Bij een ledensite kondig je dat het beste even aan.

Constants die ik altijd toevoeg in een hardening-ronde

Een handvol constants verandert het gedrag van WordPress op een manier die het aanvalsoppervlak verkleint. Wat ik standaard zet:

php

define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
define('WP_AUTO_UPDATE_CORE', 'minor');

DISALLOW_FILE_EDIT verbergt de theme- en plugin-code-editor in /wp-admin. Een gecompromitteerd admin-account kan dan niet zomaar PHP injecteren via de browser. Niet waterdicht (FTP-toegang blijft), wel een drempel.

FORCE_SSL_ADMIN forceert HTTPS op /wp-admin. Standaard zou dat al via je server moeten lopen, maar dit is een vangnet.

WP_AUTO_UPDATE_CORE op minor zorgt dat security-releases automatisch worden geinstalleerd, major-releases niet (die wil je testen).

Op gesloten beheerde sites zet ik soms ook DISALLOW_FILE_MODS op true. Dat blokkeert ook plugin-installatie via het dashboard. Handig op productie-sites die alleen via Git of een deploy-flow worden bijgewerkt. Niet aanzetten als de klant zelf plugins moet kunnen installeren.

Heb je twijfel of een specifieke constant veilig kan op jouw stack? Direct contact en ik kijk mee.

WP_DEBUG, WP_DEBUG_LOG en wat NIET op productie hoort

Op productie wil je geen debug-output. Een PHP-warning die zichtbaar is in HTML kan database-paden of plugin-versies onthullen. De productie-instelling:

php

define('WP_DEBUG', false);

Heb je toch logging nodig om iets te onderzoeken, dan kun je WP_DEBUG op true zetten in combinatie met:

php

define('WP_DEBUG_LOG', '/pad/buiten/public_html/wp-errors.log');
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);

Het log-pad zet je buiten de webroot. Zet je het op de standaardlocatie /wp-content/debug.log, dan staat het bestand mogelijk publiek te lezen (afhankelijk van je server-config). De error-reporting zelf gaat via WP_DEBUG_DISPLAY: false op productie, true alleen op een staging-omgeving waar jij meekijkt.

Zet de debug-modes na een onderzoek weer uit. Een live site met WP_DEBUG aan voor weken levert grote logs en kleine lekken op.

Database-prefix en table-credentials: kleine winst, grote impact

WordPress installeert standaard met $table_prefix = 'wp_';. Geautomatiseerde scanners kennen die prefix, dus iedere SQL-injection-poging probeert eerst wp_users. Een afwijkende prefix breekt die automatische scripts niet (een gerichte aanvaller leest de prefix gewoon uit), maar filtert wel de ruis weg.

Bij een nieuwe installatie kies ik iets als wp_lp7x_. De prefix wijzigen op een bestaande site kan, maar vereist SQL-aanpassingen in meerdere tabellen plus in wp-config.php. Geen quick-win, alleen doen als de hele stack rustig is en je een goede back-up hebt.

Database-gebruiker met minimum-rechten. De WordPress-database-gebruiker hoort alleen rechten te hebben op zijn eigen database. Concreet: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX en DROP. Geen GRANT, geen FILE, geen PROCESS. En vooral: nooit de root-gebruiker als applicatie-gebruiker, ook niet “tijdelijk” tijdens de installatie.

Veel managed hosters maken dit standaard goed, maar zelf-gehoste setups of oude VPS-installaties zijn vaak met root opgezet en daarna nooit aangepast. Check het eens.

Server-laag: directe toegang blokkeren

Op de bestandslaag staat wp-config.php op chmod 440. Op de serverlaag voeg je een tweede slot toe: blokkeer directe HTTP-toegang tot het bestand. Werkt voor het zeldzame geval dat je server de PHP-handler verkeerd configureert en wp-config.php als platte tekst zou serveren.

Apache (.htaccess in de root):

<Files wp-config.php>
  Require all denied
</Files>

Nginx (in je server-block):

location ~* wp-config\.php {
  deny all;
}

Bij een goed geconfigureerde server is dit redundant. Bij een server die om wat voor reden dan ook PHP-bestanden als tekst serveert, redt het je avond. Kleine investering, geen nadeel.

Wat je beter NIET in wp-config.php zet

In wp-config zie ik soms dingen die er niet horen. De meest voorkomende:

• API-keys van externe diensten (Mailchimp, Stripe, Google Maps). Die horen in environment-variabelen op de server, niet in een PHP-bestand dat met de site mee-deployt.
• Functionele logica (custom hooks, redirects, business-rules). Dat hoort in een mu-plugin of in functions.php van een child-theme.
• Een lange lijst defines die “voor de zekerheid” zijn toegevoegd zonder dat iemand nog weet wat ze doen.

Voor secrets is de schone aanpak een library zoals PHP dotenv, of een installatie via Bedrock waarbij .env standaard is. Bedrock is een productie-ready WordPress-boilerplate die environment-variabelen netjes scheidt van code.

Multi-stack: wp-config.php is WordPress-only. In Laravel, Statamic en headless setups vervangt .env deze rol. De principes blijven gelijk: niet in git, file-permissions strikt, niet publiek bereikbaar.

Checklist en wanneer je hulp inschakelt

De volgorde waarop ik dit op een nieuwe site uitvoer:

1. Back-up van wp-config.php en de database
2. File-permissions naar 440 zetten
3. Salts roteren via de WordPress-generator
4. DISALLOW_FILE_EDIT en FORCE_SSL_ADMIN toevoegen
5. WP_DEBUG uitzetten op productie
6. Database-rechten checken en zo nodig beperken
7. Apache- of Nginx-regel toevoegen
8. Bij nieuwe sites: table-prefix wijzigen en bestand buiten webroot zetten
9. Een tweede paar ogen, bij voorkeur op staging eerst

Wil je dat dit op één site of meerdere wordt uitgerold zonder downtime? Een hardening-ronde op een standaard WordPress duurt 1-2 uur en valt onder het kantoorstarief van €70 per uur. Avond en weekend gaan op €95 per uur, ongeplande spoed op €105. Meer over WordPress onderhoud en wat er in een hardening-pakket zit.

Voor een breder beeld van WordPress-hardening is de officiele documentatie van WordPress over hardening een goede aanvulling. Engelstalig en uitgebreid.