wp-config.php: beveiligingsinstellingen voor WordPress

Het bestand wp-config.php bevat de toegangsgegevens van de database en de geheimen waarmee je sessies worden ondertekend. Sommige constanten erin maken een WordPress-site duidelijk sterker, andere schakelen, als je ze verkeerd begrijpt, ongemerkt beschermingen uit. Dit is wat elke instelling werkelijk doet, gecontroleerd in de huidige broncode van WordPress, en de aanbevolen configuratie voor productie.

Sleutels en salts: waar ze echt voor dienen

Het voorbeeldbestand wp-config-sample.php definieert acht constanten: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY en hun vier bijbehorende salts. Ze dienen om de inlogcookies en beveiligingstokens (nonces) van WordPress te ondertekenen. Een aanvaller die ze kent, kan geldige cookies maken; een site die de voorbeeldwaarden laat staan, is dus ernstig blootgesteld.

Twee misverstanden moeten worden rechtgezet:

ze dienen niet om de wachtwoorden van gebruikers te hashen. Sinds WordPress 6.8 worden die gehasht met bcrypt, los van deze constanten;
als je ze wijzigt, wordt iedereen uitgelogd: het commentaar in het voorbeeldbestand vermeldt dat alle sessies ongeldig worden.

Genereer ze met de officiële dienst https://api.wordpress.org/secret-key/1.1/salt/, die acht regels teruggeeft die je zo kunt plakken.

Moet je ze regelmatig wijzigen?

Nee, niet zonder reden. De hardeningdocumentatie van WordPress verwijst zelf naar een technische analyse met de titel "waarom je je salts niet zou moeten wijzigen". Het argument: veel plugins gebruiken deze waarden om gegevens te versleutelen, bijvoorbeeld geheimen voor tweestapsverificatie of API-sleutels. Wijzig je ze, dan worden die gegevens onleesbaar. Wijzig ze wanneer ze mogelijk zijn uitgelekt: gehackte site, blootgestelde back-up, per ongeluk gepubliceerd bestand, vorige dienstverlener.

De bestandseditor uitschakelen: DISALLOW_FILE_EDIT

Standaard kan een beheerder de PHP-code van thema's en plugins vanuit het Dashboard bewerken. Als een beheerdersaccount wordt gestolen, wordt de editor een directe manier om code te injecteren.

define( 'DISALLOW_FILE_EDIT', true );

Volgens de hardeninghandleiding van WordPress komt deze regel neer op het intrekken van de capabilities edit_themes, edit_plugins en edit_files. Dezelfde handleiding noemt ook de grenzen: ze verhindert niet dat een aanvaller via andere wegen kwaadaardige bestanden uploadt. Het is een maatregel zonder bijwerkingen voor bijna alle sites, die je altijd zou moeten toepassen.

DISALLOW_FILE_MODS: sterker, en riskanter

DISALLOW_FILE_MODS gaat verder: het blokkeert ook het installeren en bijwerken van plugins en thema's vanuit het Dashboard. Maar de WordPress-code laat een minder bekend effect zien: de functie wp_is_file_mod_allowed() geeft voor alle contexten false terug, ook voor die van het programma voor automatische updates. Met deze constante worden de kleine beveiligingsupdates van de core niet meer vanzelf geïnstalleerd.

Gebruik haar alleen op sites waarvan de updates via een andere weg worden uitgerold (Git, deploymenttool, hostingprovider), met een proces dat de patches echt volgt.

FORCE_SSL_ADMIN: vaak al actief

FORCE_SSL_ADMIN dwingt HTTPS af voor het inloggen en het beheer, zodat wachtwoorden en cookies nooit onversleuteld over de lijn gaan. Het bestand default-constants.php laat zien dat WordPress haar automatisch op true zet als je haar niet definieert en het siteadres met https begint. Haar expliciet definiëren blijft nuttig om de keuze vast te leggen, of als het opgeslagen adres nog http is. De oude constante FORCE_SSL_LOGIN is verouderd sinds WordPress 4.0.

WP_DEBUG in productie

Debuggen is onmisbaar tijdens de ontwikkeling en gevaarlijk in productie, om twee redenen.

Het tonen van fouten (WP_DEBUG_DISPLAY, standaard true als WP_DEBUG actief is) onthult bestandspaden, queries en pluginnamen aan elke bezoeker.
Het logbestand (WP_DEBUG_LOG op true) wordt standaard weggeschreven in wp-content/debug.log, een adres dat alle bots kennen. Het kan gevoelige gegevens bevatten: in 2024 berustte een kwetsbaarheid in LiteSpeed Cache (CVE-2024-44000) juist op sessiecookies die in dit bestand werden geschreven.

Houd WP_DEBUG in productie op false. Voor een eenmalige diagnose accepteert WP_DEBUG_LOG sinds WordPress 5.1 een pad: zet het logbestand buiten de webroot en schakel het tonen uit.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/account/logs/wp-debug.log' ); // buiten de webroot

Verwijder deze regels en het logbestand zodra het probleem is opgelost.

Drie kolommen met constanten: toevoegen (DISALLOW_FILE_EDIT, WP_DEBUG op false, unieke sleutels), controleren (FORCE_SSL_ADMIN, automatische updates, omgeving), met voorzichtigheid (DISALLOW_FILE_MODS, salts vernieuwen, debuglog) — De beveiligingsconstanten ingedeeld naar risiconiveau.

Constante	Aanbevolen waarde in productie	Gecontroleerd effect	Valkuil
Sleutels en salts	Unieke gegenereerde waarden	Ondertekenen cookies en nonces	Wijzigen logt iedereen uit en kan versleutelde gegevens onbruikbaar maken
`DISALLOW_FILE_EDIT`	`true`	Verwijdert de bestandseditor	Geen voor de meeste sites
`DISALLOW_FILE_MODS`	Alleen met externe deployment	Blokkeert installaties en updates	Schakelt ook automatische updates uit
`FORCE_SSL_ADMIN`	`true`	Beheer via HTTPS	Standaard al true als het siteadres https is
`WP_DEBUG`	`false`	Schakelt de debugmodus uit	Standaard openbaar logbestand in wp-content
`WP_AUTO_UPDATE_CORE`	`'minor'` (standaard) of `true`	Regelt de automatische core-updates	`false` schakelt ook de beveiligingsupdates uit
`WP_ENVIRONMENT_TYPE`	`'production'`	Geeft het type omgeving aan	Onbekende waarde: standaard `production`

Overzicht van de beveiligingsconstanten

Waar je wp-config.php plaatst

Eén niveau boven de root

Het bestand wp-load.php zoekt wp-config.php in de WordPress-map en, als het daar niet staat, één niveau hoger, op voorwaarde dat die bovenliggende map zelf geen wp-settings.php bevat (om twee geneste installaties niet te verwarren). Het bestand buiten de webroot plaatsen garandeert dat het nooit via een eenvoudig verzoek kan worden geserveerd.

Mappenstructuur met wp-config.php boven de map public_html, en de drie zoekstappen van wp-load.php — WordPress vindt zelf een wp-config.php die één niveau boven zijn root staat.

De hardeninghandleiding van WordPress erkent dat het voordeel omstreden is: zolang PHP werkt, wordt het bestand nooit getoond, omdat het wordt uitgevoerd. Verplaatsen beschermt vooral tegen het geval dat de server PHP niet meer uitvoert en de bestanden als platte tekst serveert. Op gedeelde hosting waar WordPress rechtstreeks in public_html staat, is het eenvoudig en zonder risico; in een submap controleer je eerst de structuur.

Rechten en blokkade op de server

Rechten: de hardeninghandleiding raadt aan dat alleen jij en de webserver het bestand kunnen lezen, wat meestal overeenkomt met 400 of 440. Afhankelijk van de hostingprovider kan 600 of 640 nodig zijn.
Onder Apache of LiteSpeed blokkeert een blok <Files "wp-config.php"> met Require all denied in de .htaccess rechtstreekse verzoeken.
Laat nooit kopieën rondslingeren: wp-config.php.bak, wp-config.old of wp-config.php~ worden niet uitgevoerd door PHP en zouden als platte tekst worden geserveerd, inclusief wachtwoorden.

Met WP Masquerade

WP Masquerade wijzigt nooit wp-config.php of de core-bestanden. De botvallen van de gratis versie tellen verzoeken naar gevoelige bestanden zoals .bak-back-ups, wat laat zien waar bots op je site naar zoeken. Met de Pro-versie versleutelt de tweestapsverificatie de geheimen van gebruikers met de sleutels van de site: de handleiding wijst erop dat je na een wijziging van de sleutels moet inloggen met een herstelcode en daarna tweestapsverificatie opnieuw moet activeren. De integriteitscontrole vergelijkt de core-bestanden met de officiële checksums, waarbij wp-config.php, dat per site verschilt, bewust wordt uitgesloten.

Franstalige video (WPMarmite): drie misverstanden over het bestand wp-config.php en de beveiliging ervan.

Franstalige video: het bestand wp-config.php buiten de webroot plaatsen.

Lees ook: WordPress-fouten begrijpen en je site debuggen.

Lees ook: WordPress multisite installeren en een netwerk van sites aanmaken.

Om te onthouden

Sleutels en salts ondertekenen cookies en nonces; genereer ze met de officiële dienst en wijzig ze alleen bij een lek.
DISALLOW_FILE_EDIT is een veilige maatregel; DISALLOW_FILE_MODS schakelt ook de automatische updates uit.
FORCE_SSL_ADMIN is standaard al actief als het siteadres https is.
In productie: WP_DEBUG op false, en nooit een logbestand in een openbare map.
WordPress accepteert een wp-config.php die één niveau hoger staat; verwijder elke back-upkopie van het bestand.

Bronnen

Andere geraadpleegde bronnen: officiële pagina's van de leveranciers en publicaties van beveiligingsonderzoekers.

wp-config.php: de beveiligingsinstellingen die er echt toe doen