Le fichier wp-config.php n’est pas seulement un emplacement où WordPress “trouve” sa base de données. C’est un levier de sécurité très concret, parce qu’il concentre des secrets, des paramètres qui influencent le comportement du site, et parfois des choix de configuration qui exposent inutilement des informations.
Sur le terrain, j’ai vu trois scénarios revenir sans cesse. Le premier: des identifiants en clair dans un dépôt Git, parfois avec un fichier non ignoré. Le deuxième: des développeurs qui activent le mode debug sur un site en production, ce qui finit par afficher des chemins serveur et des détails de configuration. Le troisième: des installations où le préfixe de table et les constantes de WordPress restent à des valeurs par défaut, parce que “ça marche”. Ça marche, jusqu’au jour où un bot tombe dessus, ou qu’une fuite de données arrive par un autre vecteur.
Dans ce billet, je me concentre sur la sécurisation WordPress via une configuration de base robuste de wp-config.php. L’objectif n’est pas de tout verrouiller au point de casser des plugins, mais de réduire la surface d’attaque, de limiter les fuites d’informations et d’augmenter la résilience.
Comprendre ce que wp-config.php contrôle vraiment
WordPress lit wp-config.php très tôt lors du chargement. Le fichier contient notamment:
- les identifiants de connexion à la base de données, le nom de la base et le serveur, le préfixe des tables, des constantes de sécurité liées aux clés et sel secrets, des options de debug et de chargement.
Ce qui rend le fichier critique, c’est que les paramètres qu’il contient se répercutent immédiatement sur le comportement du site, même avant l’authentification. Si vous fixez des constantes de sécurité, si vous désactivez les affichages verbeux, si vous réduisez les informations révélées, vous agissez avant que la requête n’atteigne le reste de WordPress.
Autre point à garder en tête: wp-config.php ne remplace pas les bonnes pratiques au niveau serveur (droits de fichiers, durcissement web, pare-feu, mises à jour), mais c’est un niveau de contrôle que vous pouvez maîtriser.
Préparer un fichier sain avant d’attaquer la sécurité
Avant de modifier quoi que ce soit, prenez deux précautions simples, mais non négociables.
D’abord, faites une copie de sauvegarde de wp-config.php en local, pas seulement dans l’interface du fournisseur. Une restauration propre en cas d’erreur est souvent plus rapide que de diagnostiquer après coup.
Ensuite, appliquez une méthode: vous changez une ou deux choses, vous testez, puis vous passez à la suite. WordPress casse rarement d’un coup, mais quand ça arrive, vous voulez savoir exactement quel paramètre est en cause.
Dans un contexte de sécurisation WordPress, je conseille aussi de vérifier que le fichier est versionné ou non dans votre flux de déploiement. Si https://gardewp.fr/securite-wordpress/ vous utilisez Git, il vaut mieux que wp-config.php n’entre jamais dans le dépôt. Il existe des workflows où on versionne un modèle sans secrets et où on génère le fichier final en déploiement. C’est plus de discipline au début, mais nettement moins de risques ensuite.
Les clés et sels: la sécurité des sessions, pas un gadget
Dans tout wp-config.php propre, vous trouverez des lignes du type:
Define('AUTH_KEY', '...valeur...'); Define('SECURE_AUTH_KEY', '...valeur...'); Define('LOGGED_IN_KEY', '...valeur...'); Define('NONCE_KEY', '...valeur...'); Define('AUTH_SALT', '...valeur...'); Define('SECURE_AUTH_SALT', '...valeur...'); Define('LOGGED_IN_SALT', '...valeur...'); Define('NONCE_SALT', '...valeur...');Ces constantes améliorent la sécurité des sessions et des mécanismes de jetons. Elles sont liées au fait que WordPress signe des informations côté serveur et s’appuie sur des valeurs aléatoires et uniques.
Sur le terrain, c’est là que l’on voit le plus souvent deux problèmes:
1) des valeurs manifestement faibles, réutilisées d’une installation à l’autre, parfois parce qu’on a copié un fichier existant, 2) un wp-config.php qui a déjà été exposé. Dans ce cas, même si la fuite n’est pas publique, vous ne savez pas qui a pu le consulter.
Règle pratique: si vous suspectez une exposition (capture d’écran, fichier envoyé par erreur, fuite via dépôt), vous changez immédiatement ces clés et sels. Ce changement invalide les sessions existantes. C’est le bon comportement, même si vous devez ensuite redemander la connexion aux utilisateurs.
Pour les générer, on s’appuie sur des outils fournis par l’écosystème WordPress. L’idée n’est pas de “tenter” des valeurs maison, mais d’obtenir des chaînes suffisamment aléatoires. Ensuite, vous remplacez les anciennes valeurs dans wp-config.php et vous sauvegardez.
Le préfixe des tables: pas une panacée, mais un vrai plus
Le préfixe des tables est une ligne classique:
$table_prefix = 'wp_';Le risque n’est pas que le préfixe “protège” à lui seul. Un attaquant motivé peut toujours explorer la base, et surtout, il peut chercher d’autres signaux. Mais utiliser un préfixe par défaut, c’est offrir un indice. Beaucoup de scripts automatisés gagnent du temps avec des hypothèses.
Quand vous configurez une installation, changer le préfixe avant la mise en production est une bonne pratique. Quand vous migrez un site existant, modifier le préfixe peut être délicat, car il faut adapter la base et vérifier les plugins qui auraient des requêtes codées en dur. Si votre installation est déjà en production, je traite cette question au cas par cas, et je privilégie une approche de migration propre avec test, plutôt que de “bricoler”.
En sécurisation WordPress, le préfixe n’est pas l’élément le plus spectaculaire, mais c’est un signal faible à corriger, surtout sur un site neuf.
La base de données: identifiants, serveur et droits
La section base de données dans wp-config.php ressemble généralement à ceci:
Define('DB_NAME', 'nom_de_la_base'); Define('DB_USER', 'utilisateur'); Define('DB_PASSWORD', 'mot_de_passe'); Define('DB_HOST', 'localhost');Ici, la sécurité passe autant par la qualité des identifiants que par la discipline de configuration.
Premier réflexe: des mots de passe longs et uniques pour l’utilisateur de base de données WordPress. Un mot de passe court, même “pas trop mauvais”, se fait casser plus vite que vous ne le pensez. Sur des hébergements partagés, je vois parfois des utilisateurs DB créés avec des droits trop larges. Idéalement, le compte a uniquement les droits nécessaires pour lire et écrire les tables du WordPress, et rien de plus.
Deuxième réflexe: si le hosting sépare les bases ou utilise un accès réseau, vérifiez la valeur de DB_HOST. Certaines plateformes utilisent des sockets, d’autres des noms d’hôte internes. Modifier DB_HOST peut casser le fonctionnement si vous n’êtes pas aligné avec la plateforme. En sécurité, ne touchez pas à cette valeur sans documentation.
Troisième réflexe: traquez l’exposition. Le plus gros risque n’est pas “un attaquant essaie des mots de passe”, c’est “le fichier a fuit”. Donc, même si vous mettez un très bon mot de passe, si wp-config.php est lisible depuis l’extérieur ou accessible via mauvaise config web, vous perdez.
C’est là que la configuration serveur et les droits de fichiers prennent le relais. Mais dans wp-config.php, vous pouvez au moins vous assurer de ne jamais activer de mode verbeux en production, ce qui limiterait les fuites indirectes.
Le mode debug: la source la plus fréquente de fuite d’informations
Dans la pratique, c’est souvent la ligne WP_DEBUG qui fait basculer un site.
Si vous activez le debug en production, WordPress peut afficher des erreurs PHP, des chemins système, des noms de plugins, et parfois des éléments de configuration. Même si tout ne fuit pas systématiquement, le risque augmente fortement.
Pour une base de sécurisation WordPress, je vise un état simple:
- en production: debug désactivé, en développement: debug activé, avec une journalisation contrôlée et pas d’affichage côté navigateur.
Concrètement, on voit parfois dans wp-config.php:
Define('WP_DEBUG', false); Define('WP_DEBUG_LOG', false); Define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0);Je vous conseille de rester cohérent entre les constantes WordPress et les réglages PHP. Si WP_DEBUG_DISPLAY est à false mais que PHP affiche encore des erreurs, vous perdez le bénéfice. À l’inverse, si vous loggez sans maîtriser l’accès aux logs, vous créez une autre surface.
Un détail qui m’a déjà sauvé: WP_DEBUG_LOG peut écrire dans wp-content/debug.log. Si votre hébergement ou vos règles web exposent ce dossier, vous venez d’autoriser la lecture de traces. Donc en production, mieux vaut ne pas logguer debug, sauf besoin ponctuel.
Limiter l’exécution de code inutile: l’approche “ne pas surprendre WordPress”
WordPress exécute beaucoup de code via les thèmes et plugins. Dans wp-config.php, il existe des directives qui influencent la vitesse, la compatibilité ou le comportement du chargement. La tentation est de “optimiser” en empilant des constantes.
Pour une stratégie de sécurisation WordPress, je préfère la discipline suivante: dans wp-config.php, ne mettez que ce qui réduit des risques, ou ce qui répond à un besoin clair.
Quelques constantes peuvent être utiles selon votre contexte, mais elles ne doivent pas être activées à l’aveugle. Par exemple, certaines options qui changent la façon dont WordPress gère les mises à jour automatiques peuvent être pertinentes pour des environnements où vous testez en préproduction. Mais ce n’est pas un mécanisme de sécurité direct. Si vous n’avez pas de raison opérationnelle, restez minimaliste.
La règle d’or que je répète: chaque constante ajoutée est une responsabilité de maintenance. Quand WordPress évolue, quand un plugin interagit différemment, vous devez pouvoir expliquer pourquoi vous avez ajouté cette ligne.
Empêcher l’écriture directe et gérer les droits: ce qui se joue avant même WordPress
Même si wp-config.php ne contient pas les réglages de droits, il est au cœur du sujet parce que c’est un fichier qui doit rester non modifiable publiquement et protégé.
Sur les hébergements classiques, la protection se fait via les règles du serveur. Dans le monde WordPress, le standard est que wp-config.php ne soit pas servi au navigateur. Les erreurs 403 ou 404 à la tentative d’accès direct doivent être la norme.
Si vous avez déjà eu l’occasion d’auditer un site, vous savez que c’est parfois trompeur: le site marche, mais le fichier est téléchargeable. Un bot n’a pas besoin d’exploit complexe. Il scanne, il teste, il tente des URLs standard.
Donc même si ce billet se concentre sur wp-config.php, la sécurisation WordPress passe par une vérification de l’accessibilité. Vous pouvez faire un test simple, depuis l’extérieur, en tentant l’accès direct au fichier. Si vous obtenez une réponse texte, ou pire, le contenu du fichier, il faut corriger immédiatement.
Je ne donne pas ici de commandes serveur détaillées, car elles dépendent fortement d’Apache, Nginx, et des règles de l’hébergeur. Mais côté configuration, l’idée est claire: wp-config.php doit rester en lecture côté système, pas côté public.
Exemple de configuration robuste de base (structure, pas valeurs)
Voici à quoi ressemble une structure saine de wp-config.php pour la partie “sécurité et configuration”, en gardant les valeurs à adapter.
Je vous donne volontairement une version générique, parce que les constantes et leurs valeurs doivent rester propres à votre base de données et à votre hébergement. L’objectif est que vous sachiez où placer les réglages et quelles intentions suivre.
<?php Define('DB_NAME', 'votre_base'); Define('DB_USER', 'votre_utilisateur'); Define('DB_PASSWORD', 'votre_mot_de_passe'); Define('DB_HOST', 'localhost'); Define('DB_CHARSET', 'utf8'); Define('DB_COLLATE', ''); $table_prefix = 'wp_1234_'; Define('AUTH_KEY', '...') Define('SECURE_AUTH_KEY', '...') Define('LOGGED_IN_KEY', '...') Define('NONCE_KEY', '...') Define('AUTH_SALT', '...') Define('SECURE_AUTH_SALT', '...') Define('LOGGED_IN_SALT', '...') Define('NONCE_SALT', '...'); Define('WP_DEBUG', false); Define('WP_DEBUG_LOG', false); Define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0); If ( !defined('ABSPATH') ) Define('ABSPATH', __DIR__ . '/'); Require_once ABSPATH . 'wp-settings.php'; <p> Deux remarques importantes, issues des erreurs que j’ai vues:- Ne changez pas ABSPATH au hasard. La ligne doit rester cohérente avec votre structure de fichiers. Ne laissez pas WP_DEBUG à true “pour voir”. Si vous devez diagnostiquer un souci ponctuel, vous le faites de façon temporaire, et vous revenez en arrière vite, de préférence en effectuant vos tests sur un environnement de staging.
Sécuriser sans casser: le bon compromis pour une production réelle
Les plugins de cache, les plugins de sécurité, et parfois des extensions e-commerce changent leur comportement selon l’état de debug. Certains plugins peuvent aussi produire des logs en fonction des constantes.
Dans un projet que j’ai mené, un site de vente en ligne avait un debug activé “juste pour les erreurs”. Résultat: des erreurs parse PHP apparaissaient seulement pour certains rôles, notamment quand un administrateur visitait la page d’édition. Ça rendait les symptômes “flous” côté équipe, parce que tout semblait fonctionner ailleurs. Une fois debug désactivé et les logs recentrés, le comportement est devenu lisible et le support a pu trier les vrais problèmes.
Autrement dit, sécuriser, ce n’est pas uniquement désactiver. C’est aussi rendre votre système plus prédictible.
Checklist de base pour une sécurisation WordPress via wp-config.php
Je vous propose une checklist courte, orientée production. Elle n’est pas exhaustive, mais elle couvre les erreurs fréquentes liées à ce fichier.
Vérifiez que WP_DEBUG est à false en production, et que WP_DEBUG_DISPLAY est à false. Remplacez les clés et sels par des valeurs uniques et suffisamment aléatoires, et régénérez-les en cas de suspicion d’exposition. Évitez le préfixe wp_ par défaut, au moins sur une installation neuve, avec une migration propre si le site existe déjà. Utilisez un utilisateur de base de données avec des droits minimaux nécessaires, et un mot de passe long et unique. Testez l’accès externe à wp-config.php pour confirmer qu’il n’est pas téléchargeable depuis le navigateur.Deux pièges que je rencontre encore
1) Le fichier est “protégé”, mais le repository ne l’est pas
Je l’ai vu plusieurs fois, même sur des équipes sérieuses: le fichier n’est pas accessible via le web, mais une copie a été ajoutée dans un dépôt, ou un ZIP de déploiement a été envoyé à un canal non sécurisé. Dans ce cas, la meilleure configuration wp-config.php ne compense rien. La sécurisation WordPress commence par la gestion des secrets.
Concrètement, même si vous utilisez un bon mot de passe, si les clés et identifiants apparaissent dans un historique Git accessible, vous devez agir: révoquer, régénérer clés et sels, et changer le mot de passe de la base de données.
2) “On met WP_DEBUG_LOG pour voir”, puis les logs deviennent une fuite
WP_DEBUG_LOG peut être utile en dépannage, mais uniquement si le fichier de log n’est pas exposé et si vous contrôlez qui y a accès. Un log, même sans données sensibles directes, peut contenir des détails sur la stack, des chemins serveur, et des indices sur des erreurs de plugins.
Je recommande une règle opérationnelle: quand vous activez un mode de debug, vous le faites pour un diagnostic court, vous surveillez l’emplacement exact des logs, et vous revenez à un état “silencieux” dès que vous avez identifié la cause.
Ajustements selon votre contexte: hébergement, staging, et équipe
Tous les sites ne suivent pas la même logique. Si vous avez un environnement de staging, vous pouvez garder WP_DEBUG à true dans staging et rester à false en production. Le gain est réel: vous détectez rapidement des erreurs sans risquer une fuite côté public.
Si vous travaillez en équipe, la cohérence devient essentielle. Un développeur qui modifie wp-config.php en production “pour tester” est typiquement une source de chaos. Le bon modèle consiste à isoler les configurations par environnement, et à ce que wp-config.php soit généré ou déployé de manière contrôlée.
Côté sécurité, il y a aussi un autre point, plus humain: la rotation. Si vous changez un mot de passe base de données, pensez à ceux qui dépendent de ce secret. Si vous réinitialisez clés et sels, anticipez l’impact sur la connexion des utilisateurs. Ce n’est pas un bug, mais cela doit être anticipé.
Exemple de procédure de changement sans interruption (idée, pas une méthode miracle)
Quand vous devez régénérer les clés et sels ou modifier des identifiants, essayez de le faire pendant une fenêtre où vous pouvez observer le comportement du site. Les changements sont généralement immédiats, mais en cas d’erreur de syntaxe ou de valeur incorrecte, WordPress ne démarre plus. Une sauvegarde et un retour rapide sont donc importants.
Sur un projet, nous avons modifié les clés et sels sur la journée. Les utilisateurs ont été déconnectés, puis ont reconnecté sans friction notable. Par contre, l’équipe support avait été prévenue, donc elle n’a pas perdu de temps. C’est un point souvent sous-estimé: la sécurité se traduit aussi par une communication interne.
Ce que wp-config.php ne peut pas faire à lui seul
Pour rester honnête, certaines mesures de sécurité passent ailleurs:
- le durcissement serveur (droits fichiers, règles d’accès), la gestion des mises à jour WordPress, thèmes et plugins, la protection contre les attaques applicatives via plugins spécialisés ou pare-feu, la limitation des tentatives de connexion et la gestion des comptes.
wp-config.php est un socle, pas l’armure complète. Mais un socle solide réduit l’impact de plusieurs scénarios. Par exemple, un debug correctement désactivé réduit la probabilité de divulgation d’indices. Une gestion propre des secrets réduit le risque post-fuite.
Recommandations finales, orientées action
Si vous voulez une approche simple et efficace de sécurisation WordPress, partez de wp-config.php comme d’une “barrière intérieure”. Vous cherchez à:
- empêcher les fuites d’informations via debug, rendre les sessions plus difficiles à forger via clés et sels, réduire les signaux faciles (préfixe), assurer une connexion base de données cohérente et sans secrets exposés.
Le plus important, dans le quotidien, c’est la constance. Les configurations “juste pour aujourd’hui” finissent souvent par rester des semaines. Et c’est rarement le type d’accident que vous voulez.
Si vous voulez, je peux aussi vous aider à faire une relecture de votre wp-config.php en vous demandant seulement les parties “non sensibles” (en masquant nom de base, utilisateur, mots de passe et valeurs des clés). Vous garderez votre sécurité, et on pourra identifier les points à améliorer sans vous mettre en risque.