Un site WordPress peut paraître “juste” une vitrine, puis un jour on découvre que tout repose sur un seul fichier. Wp-config.php fait partie de ceux-là. Il contient la connexion à la base de données, parfois des chemins sensibles, et surtout les clés de sécurité (les “auth keys” et “salt”) qui protègent la session des utilisateurs. Si ce fichier est exposé ou si ses secrets sont réutilisés, les conséquences peuvent aller du piratage de comptes à la prise de contrôle du site.
Dans cet article, je vais parler de ce qui marche vraiment en conditions réelles, avec des choix concrets, des compromis, et des erreurs fréquentes. Objectif: sécuriser wp-config.php, puis traiter correctement les clés API qui finissent par se retrouver dedans (ou ailleurs dans le projet), sans casser le site ni multiplier les risques.
Pourquoi wp-config.php est une cible logique
Wp-config.php n’est pas un fichier “décoratif”. C’est la brique de démarrage. https://gardewp.fr/securite-wordpress/ WordPress l’utilise pour se connecter à la base de données et pour appliquer des mécanismes de sécurité liés à l’authentification et aux cookies.
Quand un attaquant obtient:
- le contenu de wp-config.php, il peut souvent préparer une attaque plus efficace (connexion à la base, repérage des noms de tables, déduction d’un environnement); les clés de sécurité et salts, il peut rendre plus faciles certains scénarios de détournement de sessions si la configuration est ancienne, faible, ou réutilisée; les identifiants d’API, il peut exploiter vos services tiers à vos frais, ou nuire à la réputation du projet (par exemple en déclenchant des quotas, en modifiant des paramètres, ou en ouvrant des endpoints).
Le point délicat, c’est que même “bien configuré”, le site peut rester vulnérable s’il y a une fuite via une mauvaise règle serveur, une sauvegarde exposée, ou un accès trop large aux fichiers.
Ce que contient wp-config.php, et ce que vous devez considérer comme “secret”
En pratique, wp-config.php contient au minimum:
- les constantes de connexion à la base de données: DB NAME, DBUSER, DB PASSWORD, DBHOST; les préfixes de tables: souvent $table_prefix; l’ensemble des clés et salts: AUTH KEY, SECUREAUTH KEY, LOGGEDIN KEY, NONCEKEY et leurs variantes; des options de configuration liées au comportement, parfois des constantes additionnelles.
Tout ce qui ressemble à un secret mérite d’être traité comme tel, même si “ça a toujours été comme ça”. Il y a deux catégories à distinguer.
D’abord les secrets “de sécurité WordPress”: AUTH_KEY et co. Ce sont eux qui empêchent la réutilisation efficace de cookies compromis, surtout lorsque l’environnement change et que les sessions doivent expirer proprement.
Ensuite les secrets “d’exploitation”: identifiants DB et toute clé d’API présente. Même si vous pensez que les attaques ne visent pas votre base, la fuite de DB USER et DBPASSWORD simplifie beaucoup la vie d’un attaquant.
Les scénarios qui mènent à une exposition de wp-config.php
On voit souvent les mêmes causes. Elles ne sont pas spectaculaires, elles sont plutôt “bêtes” et donc fréquentes.
Un premier cas, c’est l’accessibilité directe du fichier via le web, généralement parce que la configuration serveur n’empêche pas la lecture de wp-config.php. Sur certains hébergements, une règle mal écrite dans .htaccess ou un changement de configuration peut rouvrir l’accès.
Un second cas, c’est l’exposition via des backups ou des fichiers temporaires: wp-config.php.bak, wp-config.php~ , une archive de déploiement laissée à la racine, ou un dossier “dump” oublié. Les attaquants ne cherchent pas forcément wp-config.php exactement, ils testent la variante.
Un troisième cas, plus insidieux, c’est le mauvais comportement d’un plugin qui écrit des fichiers dans des zones publiques, ou un thème qui “logge” des constantes dans un fichier de debug. Là, wp-config.php n’est pas lu directement, mais le contenu fuit autrement.
Renforcer l’accès à wp-config.php au niveau serveur
La défense la plus robuste consiste à empêcher toute lecture directe de wp-config.php depuis le web. WordPress ne peut pas “se protéger lui-même” contre une exposition externe: si le serveur laisse passer, WordPress n’a pas de levier fiable.
1) Vérifier d’abord ce que votre serveur permet réellement
Avant de modifier, je recommande toujours un test simple. Prenez votre URL de wp-config.php (celle du fichier à la racine de l’installation) et vérifiez si une réponse du serveur indique une lecture possible, un listing, ou un “403 interdit”.
Selon la configuration, vous pouvez voir un 403, un 404, ou parfois un message d’erreur PHP. Une réponse “lisible” qui contient du contenu, même partiellement, est un drapeau rouge.
Ce test vaut aussi pour des variantes, notamment si vos déploiements créent des fichiers suffixés. Une seule requête peut vous éviter des heures de confusion ensuite.
2) Bloquer explicitement avec .htaccess (si Apache)
Sur les installations qui utilisent Apache, la pratique courante consiste à ajouter des règles dans .htaccess pour refuser l’accès à wp-config.php et à ses variantes de sauvegarde.
Voici une logique générale: on refuse le fichier exact, puis on interdit les formes fréquentes (bak, backup, sauvegarde, copie). Le détail exact dépend de votre environnement, donc je ne vais pas vous donner une “recette magique” à copier-coller sans contexte, car sur certains hébergements, la structure de répertoires ou la manière de charger .htaccess change le résultat.
Ce que je conseille, c’est de chercher la présence d’une règle existante déjà en place. Souvent, vous trouverez quelque chose du type “deny from all” ou une condition équivalente. Si rien n’existe, vous pouvez ajouter.
3) Pour Nginx, privilégier une règle d’accès globale
Si votre serveur utilise Nginx, les contrôles se font via la configuration de site (server block). L’idée reste identique: refuser la lecture des fichiers sensibles localisés dans le DocumentRoot.
Le point important, c’est que la logique “je mets une ligne dans .htaccess” ne s’applique pas ici. Sur Nginx, ça ne sert à rien. En revanche, une règle bien placée peut protéger tous vos environnements, y compris quand quelqu’un change un fichier htaccess par accident.
4) Le meilleur compromis: déplacer wp-config.php hors de la racine web
Quand c’est faisable, c’est souvent la solution la plus solide. Placer wp-config.php dans un répertoire parent, hors du DocumentRoot, empêche l’accès direct au fichier, même si une erreur serveur apparaît ailleurs.
WordPress peut charger wp-config.php depuis un chemin ajusté via la logique de chargement (et, selon la méthode, il faut veiller à la valeur correcte d’ABSPATH et au fait que wp-load.php se retrouve bien).
Ce choix a un coût: vous devez aligner vos pratiques de déploiement et documenter le déplacement, sinon un futur update ou un autre membre de l’équipe peut “réinstaller” wp-config.php à la mauvaise place. Dans une équipe, une bonne note dans le référentiel de déploiement vaut presque autant que la sécurité gagnée.
Permissions de fichiers, propriétaires, et erreurs classiques
Une règle de base, c’est que les permissions trop ouvertes ne “créent” pas la vulnérabilité, mais elles aggravent tout: fuite via un autre bug, lecture par un processus compromis, ou modification par inadvertance.
Sur une installation standard, je vise généralement:
- wp-config.php non lisible par “le monde”, modifiable uniquement par le compte utilisateur du serveur (ou le compte de déploiement), avec un propriétaire cohérent (ni root sur un hébergement applicatif sans raison, ni utilisateur aléatoire).
Les chiffres exacts dépendent de la distribution, du mode PHP (FPM ou module), et de la manière dont l’hébergement applique l’isolation. Je préfère donc raisonner en termes de principe et de test: assurez-vous que l’exécution PHP fonctionne, que WordPress peut lire wp-config.php, et que l’accès direct au fichier depuis le web reste bloqué.
Le piège de “ça marche chez moi”
Une erreur fréquente consiste à changer les permissions sur wp-config.php pour régler un souci, puis à oublier le contexte. Quelqu’un teste en FTP, voit que “le fichier s’affiche”, et conclut à tort que le site est vulnérable. L’affichage en FTP n’a pas la même signification que la lecture depuis un navigateur.
À l’inverse, une règle serveur peut empêcher la lecture web, mais laisser une copie accessible via une sauvegarde. C’est pour ça que le test “depuis le web” est indispensable.
Sécuriser les clés de sécurité WordPress (les salts) comme une donnée vivante
Les lignes AUTH KEY, SECUREAUTH KEY, LOGGEDIN KEY, NONCEKEY et les variantes sont souvent laissées telles quelles pendant des années. Ça ne rend pas automatiquement l’installation “vulnérable”, mais ça affaiblit votre posture de défense.
WordPress propose un générateur pour renouveler ces valeurs. Le renouvellement a un effet concret: les sessions existantes sont invalidées. Donc oui, c’est une action “qui casse” temporairement le confort utilisateur, mais c’est précisément ce qui rend l’opération utile après un incident, ou quand vous suspectez une fuite.
Quand je recommande de faire une rotation
Je ne tourne pas les clés tous les mois, ce serait du bruit opérationnel. En revanche, je le fais dans des situations précises:
- après un incident de sécurité (même si vous n’êtes pas sûr que wp-config.php a fuité); après un départ d’une personne qui avait accès au dépôt ou à l’hébergement; après un changement de pipeline de déploiement si des logs ont pu exposer des secrets; après une migration où vous n’avez pas la certitude que l’ancien fichier a été correctement nettoyé.
La logique est simple: une rotation est cohérente quand vous augmentez le niveau d’incertitude sur la confidentialité des secrets.
Le compromis: baisse de confort, hausse de sécurité
Le renouvellement des salts invalide les sessions. Sur un site à fort trafic, ça veut dire que certains utilisateurs devront se reconnecter. Sur un site d’entreprise, il faut le planifier, par exemple en fin de journée, et informer l’équipe support si besoin.
Je l’ai vu en production: la rotation a été faite en heure de pointe, et le support a été saturé par des “je suis déconnecté”. Techniquement, c’était attendu. L’organisation, elle, ne l’avait pas anticipé.
Que faire des clés API dans WordPress: attention aux “doubles emplacements”
Les clés API se trouvent parfois dans wp-config.php, parfois dans des fichiers séparés, parfois dans des options stockées en base, ou encore dans des variables de configuration côté hébergement.
Le problème n’est pas leur existence, c’est leur emplacement et leur rotation.
Si elles sont dans wp-config.php
C’est pratique, mais ça implique qu’elles bénéficient du même niveau de protection que la base de données. Si wp-config.php est exposé, vous perdez le contrôle sur tout ce qui est lié à ces clés.
Le traitement doit être identique à celui des autres secrets: accès serveur bloqué, permissions strictes, rotation si incident ou suspicion.
Si elles sont dans des options WordPress
Les clés stockées dans la base peuvent être plus difficiles à protéger, parce qu’elles dépendent de vos règles de sécurité autour de la base. Si un attaquant obtient un dump, ces clés suivent le sort de la base.
Dans ce cas, l’approche “protéger wp-config.php” aide moins directement, mais elle reste essentielle car elle réduit la probabilité d’un accès complet à la base.
Le risque concret: quotas, facturation, et actions non désirées
Une clé API “fuite” n’est pas toujours une catastrophe immédiate, mais elle peut coûter cher. Les API font souvent un mélange de quotas et d’actions: dans certains cas, un attaquant appelle juste des endpoints et épuise le quota, dans d’autres il déclenche des actions qui modifient des données.
Je garde en tête un cas vécu sur un projet e-commerce: une clé mal protégée, combinée à un endpoint permissif, a provoqué des centaines d’appels en quelques heures. Le problème n’était pas la compromission du site, c’était la facture et la déstabilisation du service.
Plan d’action pratique, sans casser votre site
Voici une approche pragmatique, celle que j’utiliserais avant et après une rotation de secrets.
- Faites un test d’accès web à wp-config.php et à des variantes de sauvegarde, et documentez le résultat attendu (un refus clair). Vérifiez les règles serveur et le contenu de .htaccess ou de la config Nginx, selon votre hébergement, puis appliquez des blocages explicites. Ajustez les permissions pour limiter la lecture et la modification à ce qui est nécessaire à l’exécution PHP. Renouvelez les clés de sécurité WordPress via le générateur, seulement après avoir planifié l’impact sur les sessions. Si des clés API sont présentes dans wp-config.php ou ailleurs, lancez une procédure de rotation cohérente et mettez à jour la configuration au bon endroit.
Cette séquence limite les surprises. Le point clé, c’est de bloquer l’exposition avant de considérer les secrets “sains”, puis de faire la rotation quand vous avez réduit l’incertitude.
Rotation des secrets et “gestion d’incident” version WordPress
Si vous suspectez une fuite, vous ne voulez pas juste “changer les mots de passe” au hasard. Il faut une logique.
D’abord, vous définissez ce que vous pensez avoir été exposé: wp-config.php seulement, ou aussi des clés API, ou encore des identifiants de base. Ensuite, vous agissez dans l’ordre pour réduire la fenêtre de risque.
Dans un incident, je procède souvent ainsi, en ajustant selon ce que je sais:
- Bloquer l’accès aux fichiers sensibles et vérifier les variantes de backups. Renouveler les secrets WordPress (salts) pour forcer l’invalidation des sessions. Renouveler les identifiants de base si nécessaire. Révoquer ou régénérer les clés API concernées, puis valider que l’application revient bien à un état de fonctionnement stable.
Il y a un point technique que beaucoup sous-estiment: certains paramètres sont mis en cache. Vous pouvez mettre de nouvelles valeurs dans wp-config.php et constater que tout “semble pareil” à cause d’un cache applicatif, d’un opcache, ou d’une persistance dans un plugin. Dans ces cas, ne blâmez pas la sécurité, cherchez plutôt du côté de l’invalidation.
Signaux d’alerte qui justifient un durcissement immédiat
Si vous voyez l’un de ces éléments, ne laissez pas les semaines s’accumuler.
- vous constatez des tentatives de connexion inhabituelles ou des changements massifs d’utilisateurs; vous trouvez des fichiers suspects dans la racine ou des sauvegardes créées par un outil non identifié; votre site déclenche des requêtes externes régulières depuis un plugin ou un fichier temporaire; des erreurs “permission denied” apparaissent après des changements, ce qui peut indiquer des manipulations de droits mal comprises; des clés API montrent des dépassements de quotas soudains ou des activités impossibles côté votre produit.
Validation: comment savoir que vous avez réellement sécurisé
Après chaque modification, je valide en plusieurs couches.
D’abord, côté sécurité: accès web à wp-config.php, puis absence de fichiers dérivés exposés. Ensuite, côté applicatif: le site charge correctement, les connexions à la base fonctionnent, les pages publiques répondent, et la connexion administrateur marche.
Enfin, côté sécurité des sessions: après la rotation des salts, les utilisateurs doivent pouvoir se reconnecter normalement. Si vous faites la rotation sans vérifier, vous risquez un faux sentiment de “ça marche” alors que le problème ne se voit que quand des utilisateurs changent de navigateur ou après expiration naturelle.
Un bon réflexe consiste aussi à vérifier que vous avez un enregistrement minimal de ce qui a été changé. Quand quelque chose casse, vous voulez remonter rapidement à la modification exacte, pas repartir de zéro.
Cas particulier: wp-config.php absent à la racine et installations non standard
Parfois, wp-config.php n’est pas à la racine. C’est le cas quand vous l’avez déplacé, ou lors de certaines intégrations de framework. Dans ces cas, sécuriser “le bon fichier” nécessite une vérification sur votre structure réelle.
Ce que je recommande: cherchez effectivement le chemin du fichier utilisé par WordPress. Ensuite, bloquez l’accès web à ce chemin, pas seulement à l’emplacement supposé.
Ne basez pas votre protection sur un postulat “standard”, basez-la sur la réalité de votre déploiement.
Pièges fréquents lors de la sécurisation
Même avec de bonnes intentions, on peut se tirer une balle dans le pied.
Le premier piège, ce sont les règles qui bloquent aussi votre PHP. Un blocage trop large dans .htaccess peut empêcher WordPress de charger correctement des fichiers, surtout si la règle a été copiée sans adapter le contexte.
Le second piège, c’est de “masquer” sans bloquer. Certaines configurations renvoient une erreur, mais laissent une autre route d’accès. Par exemple, une ancienne URL, un alias de répertoire, ou un chemin de backup. Vous devez viser le blocage du fichier, pas seulement une page d’erreur.
Le troisième piège, c’est de remplacer une clé sans mettre à jour les services tiers. Révoquer une clé API côté fournisseur puis oublier de mettre à jour la config, c’est la recette pour une panne. Si vous planifiez une rotation, faites-le avec une fenêtre courte, et gardez un moyen de retour en arrière (au moins un fichier de configuration préparé).
Et les plugins de sécurité dans tout ça?
Les plugins de sécurité peuvent aider, notamment pour:
- détecter des comportements suspects, limiter certaines surfaces d’attaque, durcir des paramètres WordPress.
Mais aucun plugin ne remplace la protection fondamentale au niveau serveur. Si wp-config.php reste lisible, le plugin joue surtout un rôle de pansement. La meilleure défense reste celle qui empêche l’accès direct aux fichiers sensibles.
J’ai vu des sites où un plugin faisait “beaucoup”, tout en laissant un fichier critique exposé parce qu’une règle serveur n’était pas en place. Le jour où l’attaque a eu lieu, c’est le serveur qui a tranché, pas le plugin.
Garder la sécurité vivante: organisation et routine
Un site WordPress change. Thèmes, plugins, hébergement, CI/CD, migrations. La sécurité n’est pas un sprint, c’est une routine.
Concrètement, je conseille de traiter wp-config.php et les secrets comme des artefacts qu’on révise lors de chaque changement majeur. Pas forcément à chaque mise à jour de plugin, mais quand vous modifiez la structure, le déploiement, ou l’équipe.
La mise en place d’un processus simple (qui peut être très léger) fait souvent plus que “ajouter un plugin de plus”. Par exemple, lors d’une migration, vérifiez que les backups ne sont pas exposés, que wp-config.php n’est pas retourné dans une zone publique, et que les clés API sont bien celles attendues.
Checklist de fin: ce que je veux voir avant de relâcher en production
- wp-config.php n’est pas accessible depuis le web, y compris via des variantes de sauvegarde et des chemins plausibles; les clés de sécurité WordPress ont été renouvelées au bon moment, avec anticipation sur la reconnexion des utilisateurs; les identifiants DB et toute clé API exposée ont été protégés et, si nécessaire, régénérés; les permissions permettent à PHP de lire le fichier, sans ouvrir la lecture à trop large; vous pouvez expliquer, en une minute, quelles modifications ont été faites et où, pour savoir quoi vérifier si un problème arrive.
Si vous obtenez ces cinq points, vous avez fait l’essentiel. Le reste, c’est de la qualité de maintenance, des contrôles réguliers, et la discipline de ne jamais traiter wp-config.php comme un fichier “banal”.