wp-config.php : le fichier WordPress à traiter comme un secret
Le fichier wp-config.php contient les informations qui permettent à WordPress de démarrer : accès base de données, clés de sécurité, préfixe des tables, réglages de debug et constantes de durcissement. Ce n’est pas un simple fichier technique. S’il est exposé, mal protégé ou modifié par un attaquant, tout le site peut être compromis.
Ce que contient vraiment wp-config.php
On y trouve généralement le nom de la base, l’utilisateur MySQL, le mot de passe, l’hôte, les clés d’authentification et les salts. Ces clés servent à sécuriser les cookies et sessions WordPress. Après un piratage, les renouveler force les utilisateurs à se reconnecter et réduit le risque de session persistante.
Le fichier peut aussi contenir des constantes très utiles : désactivation de l’éditeur de fichiers, restriction des modifications de plugins, configuration du debug, limite de mémoire, URL du site ou règles de cron.
Les réglages de sécurité essentiels
define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );DISALLOW_FILE_EDIT empêche l’édition directe des fichiers de thème et de plugin depuis l’admin. Ce réglage ne bloque pas un attaquant déjà maître du serveur, mais il retire une voie d’exécution simple après compromission d’un compte administrateur.
FORCE_SSL_ADMIN évite que l’administration transite en clair. Les constantes de debug doivent rester désactivées en production : afficher un chemin serveur, une requête ou un warning peut donner des informations utiles à un attaquant.
Où placer et comment protéger le fichier
WordPress peut, selon l’installation, charger wp-config.php depuis le dossier parent. Ce déplacement n’est pas une solution magique, mais il limite certains risques d’exposition directe si le serveur web est mal configuré. La vraie priorité reste de refuser l’accès HTTP au fichier et de régler correctement les permissions.
Un bon hébergement doit empêcher le téléchargement de wp-config.php. Les sauvegardes temporaires sont plus dangereuses : wp-config.php.bak, wp-config.old, wp-config.txt ou une archive ZIP en racine peuvent être servies comme de simples fichiers.
Après un incident de sécurité
- Changer le mot de passe MySQL si le fichier a pu être lu.
- Renouveler les clés et salts WordPress.
- Vérifier les constantes ajoutées ou modifiées.
- Supprimer les copies de sauvegarde exposées.
- Contrôler les permissions du fichier et du dossier parent.
- Désactiver l’affichage des erreurs en production.
Erreurs courantes
La plus fréquente consiste à laisser WP_DEBUG_DISPLAY actif. La deuxième est de stocker des accès tiers dans le fichier sans rotation possible : clés API, identifiants SMTP, tokens de services externes. Quand c’est possible, utilisez des variables d’environnement ou un fichier de configuration non servi par le web.
Un wp-config.php propre ne rend pas un site invulnérable, mais il empêche qu’un incident local devienne immédiatement une compromission complète.
