wp-config.php : réglages de sécurité WordPress

Le fichier wp-config.php contient les accès à la base de données et les secrets qui signent vos sessions. Quelques constantes y renforcent nettement un site WordPress, d'autres, mal comprises, désactivent des protections sans prévenir. Voici ce que fait réellement chaque réglage, vérifié dans le code source actuel de WordPress, et la configuration conseillée en production.

Clés et sels : à quoi ils servent vraiment

Le fichier modèle wp-config-sample.php définit huit constantes : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs quatre sels associés. Ils servent à signer les cookies de connexion et les jetons de sécurité (nonces) de WordPress. Un attaquant qui les connaît peut fabriquer des cookies valides ; un site qui garde les valeurs d'exemple est donc gravement exposé.

Deux idées reçues sont à corriger :

ils ne servent pas à hacher les mots de passe des utilisateurs. Depuis WordPress 6.8, ceux-ci sont hachés avec bcrypt, sans lien avec ces constantes ;
les changer déconnecte tout le monde : le commentaire du fichier modèle le précise, toutes les sessions deviennent invalides.

Générez-les avec le service officiel https://api.wordpress.org/secret-key/1.1/salt/, qui renvoie huit lignes prêtes à coller.

Faut-il les changer régulièrement ?

Non, pas sans raison. La documentation de durcissement de WordPress renvoie elle-même à une analyse technique intitulée « pourquoi vous ne devriez pas changer vos sels ». Son argument : de nombreuses extensions utilisent ces valeurs pour chiffrer des données, par exemple les secrets de double authentification ou des clés d'API. Les changer rend ces données illisibles. Changez-les quand ils ont pu fuiter : site piraté, sauvegarde exposée, fichier publié par erreur, ancien prestataire.

Couper l'éditeur de fichiers : DISALLOW_FILE_EDIT

Par défaut, un administrateur peut modifier le code PHP des thèmes et des extensions depuis le Tableau de bord. Si un compte administrateur est volé, l'éditeur devient un moyen direct d'injecter du code.

define( 'DISALLOW_FILE_EDIT', true );

Selon le guide de durcissement de WordPress, cette ligne revient à retirer les capacités edit_themes, edit_plugins et edit_files. Le même guide précise ses limites : elle n'empêche pas un attaquant de téléverser des fichiers malveillants par d'autres moyens. C'est une mesure sans effet de bord pour presque tous les sites, à appliquer systématiquement.

DISALLOW_FILE_MODS : plus fort, et plus risqué

DISALLOW_FILE_MODS va plus loin : il bloque aussi l'installation et la mise à jour des extensions et des thèmes depuis le Tableau de bord. Mais le code de WordPress montre un effet moins connu : la fonction wp_is_file_mod_allowed() renvoie faux pour tous les contextes, y compris celui du programme de mises à jour automatiques. Avec cette constante, les mises à jour de sécurité mineures du cœur ne s'installent plus d'elles-mêmes.

Réservez-la aux sites dont les mises à jour sont déployées par un autre moyen (Git, outil de déploiement, hébergeur), avec un processus qui suit réellement les correctifs.

FORCE_SSL_ADMIN : souvent déjà actif

FORCE_SSL_ADMIN impose HTTPS pour la connexion et l'administration, afin que mots de passe et cookies ne circulent jamais en clair. Le fichier default-constants.php montre que, si vous ne la définissez pas, WordPress la règle automatiquement à vrai lorsque l'adresse du site commence par https. La définir explicitement reste utile pour documenter le choix, ou lorsque l'adresse enregistrée est encore en http. L'ancienne constante FORCE_SSL_LOGIN est obsolète depuis WordPress 4.0.

WP_DEBUG en production

Le débogage est indispensable en développement et dangereux en production pour deux raisons.

L'affichage des erreurs (WP_DEBUG_DISPLAY, vrai par défaut quand WP_DEBUG est actif) révèle chemins de fichiers, requêtes et noms d'extensions à n'importe quel visiteur.
Le journal (WP_DEBUG_LOG à true) s'écrit par défaut dans wp-content/debug.log, une adresse connue de tous les robots. Il peut contenir des données sensibles : en 2024, une faille de LiteSpeed Cache (CVE-2024-44000) reposait précisément sur des cookies de session écrits dans ce fichier.

En production, gardez WP_DEBUG à false. Pour un diagnostic ponctuel, depuis WordPress 5.1 WP_DEBUG_LOG accepte un chemin : placez le journal hors de la racine web, et coupez l'affichage.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/compte/logs/wp-debug.log' ); // hors de la racine web

Supprimez ces lignes et le fichier de journal une fois le problème résolu.

Trois colonnes de constantes : à ajouter (DISALLOW_FILE_EDIT, WP_DEBUG à false, clés uniques), à vérifier (FORCE_SSL_ADMIN, mises à jour automatiques, environnement), avec précaution (DISALLOW_FILE_MODS, rotation des sels, journal de débogage) — Les constantes de sécurité classées par niveau de risque.

Constante	Valeur conseillée en production	Effet vérifié	Piège
Clés et sels	Valeurs uniques générées	Signent cookies et nonces	Les changer déconnecte tout le monde et peut casser des données chiffrées
`DISALLOW_FILE_EDIT`	`true`	Supprime l'éditeur de fichiers	Aucun pour la plupart des sites
`DISALLOW_FILE_MODS`	Seulement avec un déploiement externe	Bloque installations et mises à jour	Coupe aussi les mises à jour automatiques
`FORCE_SSL_ADMIN`	`true`	Administration en HTTPS	Déjà vrai par défaut si l'adresse du site est en https
`WP_DEBUG`	`false`	Désactive le mode débogage	Journal par défaut public dans wp-content
`WP_AUTO_UPDATE_CORE`	`'minor'` (défaut) ou `true`	Règle les mises à jour automatiques du cœur	`false` désactive aussi les correctifs de sécurité
`WP_ENVIRONMENT_TYPE`	`'production'`	Indique le type d'environnement	Valeur inconnue : `production` par défaut

Récapitulatif des constantes de sécurité

Où placer wp-config.php

Un niveau au-dessus de la racine

Le fichier wp-load.php cherche wp-config.php dans le dossier de WordPress, puis, s'il ne le trouve pas, un niveau au-dessus, à condition que ce dossier parent ne contienne pas lui-même un wp-settings.php (pour ne pas confondre deux installations imbriquées). Placer le fichier hors de la racine web garantit qu'il ne pourra jamais être servi par une simple requête.

Arborescence avec wp-config.php placé au-dessus du dossier public_html, et les trois étapes de recherche de wp-load.php — WordPress trouve seul un wp-config.php placé un niveau au-dessus de sa racine.

Le guide de durcissement de WordPress reconnaît que le bénéfice est discuté : tant que PHP fonctionne, le fichier n'est jamais affiché, car il est exécuté. Le déplacement protège surtout du cas où le serveur cesserait d'exécuter PHP et servirait les fichiers en texte brut. Sur un hébergement mutualisé où WordPress est installé directement dans public_html, c'est simple et sans risque ; dans un sous-dossier, vérifiez la structure.

Permissions et blocage serveur

Permissions : le guide de durcissement recommande que seul vous et le serveur web puissiez lire le fichier, ce qui correspond généralement à 400 ou 440. Selon l'hébergeur, 600 ou 640 peut être nécessaire.
Sous Apache ou LiteSpeed, un bloc <Files "wp-config.php"> contenant Require all denied dans le .htaccess bloque les requêtes directes.
Ne laissez jamais traîner de copies : wp-config.php.bak, wp-config.old ou wp-config.php~ ne sont pas exécutées par PHP et seraient servies en texte brut, mots de passe compris.

Avec WP Masquerade

WP Masquerade ne modifie jamais wp-config.php ni les fichiers du cœur. Les pièges à robots de la version gratuite comptent les requêtes vers des fichiers sensibles comme les sauvegardes .bak, ce qui montre ce que les robots cherchent sur votre site. Avec la version Pro, la double authentification chiffre les secrets des utilisateurs avec les clés du site : son guide rappelle qu'après un changement des clés, il faut se connecter avec un code de secours puis réactiver la double authentification. Le contrôle d'intégrité compare les fichiers du cœur aux sommes officielles, en excluant volontairement wp-config.php, propre à chaque site.

Vidéo en français (WPMarmite) : trois idées reçues sur le fichier wp-config.php et sa sécurité.

Vidéo en français : déplacer le fichier wp-config.php hors de la racine web.

À retenir

Les clés et sels signent cookies et nonces ; générez-les avec le service officiel et ne les changez qu'en cas de fuite.
DISALLOW_FILE_EDIT est une mesure sûre ; DISALLOW_FILE_MODS coupe aussi les mises à jour automatiques.
FORCE_SSL_ADMIN est déjà actif par défaut si l'adresse du site est en https.
En production : WP_DEBUG à false, et jamais de journal dans un dossier public.
Placer wp-config.php un niveau au-dessus est accepté par WordPress ; supprimez toute copie de sauvegarde du fichier.

Sources

Autres sources consultées : pages officielles des éditeurs et publications de chercheurs en sécurité.

wp-config.php : les réglages de sécurité qui comptent vraiment