wp-config.php contient la configuration de base de WordPress et souvent des secrets d’accès. Pour sécuriser wp-config.php, il faut limiter qui peut le lire ou le modifier, maintenir des réglages explicites par environnement et éviter d’y coller des constantes dont on ne comprend pas les conséquences.
Changer le préfixe des tables ou déplacer le fichier n’annule pas une extension vulnérable, un compte compromis ou des permissions trop larges. La sécurité vient d’un ensemble de contrôles testés et d’une procédure de récupération.
Sommaire
La réponse courte
Sauvegardez le fichier dans un emplacement protégé, vérifiez propriétaire et permissions selon l’architecture, empêchez son accès web, gardez les secrets hors des dépôts et renouvelez-les après exposition. Désactivez l’éditeur intégré si le flux de déploiement le permet.
Activez le diagnostic uniquement le temps nécessaire, en enregistrant les erreurs hors de l’affichage public. Testez toute constante sur staging et documentez son propriétaire. Ne publiez jamais le contenu réel du fichier, même avec quelques valeurs masquées.
La documentation officielle décrit `wp-config.php` comme l’un des fichiers les plus importants et avertit que ses options avancées peuvent avoir des effets imprévus.
Principes qui restent valables
Le fichier définit notamment la connexion à la base, les clés d’authentification, le préfixe et des comportements d’administration. Sa syntaxe PHP doit rester valide : une simple erreur peut rendre le site inaccessible.
Les environnements modernes injectent parfois des valeurs depuis des variables ou un gestionnaire de secrets. Cette pratique peut réduire les copies, mais elle déplace la responsabilité vers le système de déploiement ; elle ne supprime pas le besoin de contrôle d’accès.
Faire une sauvegarde protégée
Avant l’édition, conservez une copie chiffrée ou dans un dépôt privé approprié sans secrets en clair. Notez la version et la procédure de restauration. Ne laissez pas un fichier .bak lisible dans le répertoire public.
Testez la restauration sur staging. Le retour consiste souvent à remettre le fichier précédent, mais une modification associée de base ou de domaine peut demander plus.
La sauvegarde de wp-config.php ne remplace pas celle du site complet.
Contrôler propriétaire et permissions
Le processus PHP doit pouvoir lire le fichier, tandis que seules les identités nécessaires devraient pouvoir le modifier. La valeur numérique adaptée dépend du propriétaire, du groupe, du mode PHP et de l’hébergement.
Le guide WordPress sur les permissions de fichiers cite des protections plus strictes pour wp-config.php, mais avertit aussi que les environnements diffèrent. Ne recopiez pas un chmod sans comprendre les utilisateurs concernés.
Testez les mises à jour et la lecture après changement ; n’utilisez jamais 777.
Bloquer l’accès HTTP
Un serveur correctement configuré exécute PHP au lieu de livrer sa source. Ajoutez néanmoins la règle de refus recommandée pour votre serveur et vérifiez-la depuis une session déconnectée.
Testez aussi les variantes de fichiers de sauvegarde, éditeur ou archive qui pourraient être servies comme texte. Supprimez-les du webroot après usage.
Une réponse 403 ou 404 est attendue ; ne publiez pas le chemin réel du test.
Évaluer le déplacement du fichier
WordPress peut lire wp-config.php un niveau au-dessus de l’installation. Le guide de durcissement WordPress note que le bénéfice est discuté et qu’un déplacement mal réalisé peut créer des vulnérabilités.
Ne l’effectuez que si l’arborescence, les sauvegardes, le déploiement et les outils le supportent. Vérifiez que le nouvel emplacement n’est pas partagé avec un autre contexte moins protégé.
Ce déplacement ne remplace ni permissions ni refus HTTP.
Gérer les secrets de base
Les constantes de base ne doivent pas apparaître dans un dépôt public, une capture, un ticket ou un article. Restreignez le compte de base aux besoins du site et évitez sa réutilisation.
Si une valeur a été exposée, créez un nouveau secret, mettez à jour la configuration par un canal sûr, vérifiez le site puis révoquez l’ancien. Examinez les accès pendant la fenêtre d’exposition.
Ne montrez pas le format réel du nom d’hôte ou de l’utilisateur.
Renouveler les clés d’authentification
Les clés et salts participent à la protection des cookies et sessions. Les renouveler invalide les sessions existantes, ce qui peut être souhaité après un incident mais gêner des utilisateurs lors d’un changement routinier.
Planifiez la rotation, informez l’équipe et vérifiez la reconnexion. Obtenez les valeurs par la source officielle ou un mécanisme de déploiement, puis gardez-les secrètes.
Une rotation ne change pas les mots de passe des comptes.
Désactiver l’éditeur de fichiers
DISALLOW_FILE_EDIT empêche l’édition de thèmes et extensions depuis l’administration. Cela réduit les accidents et une possibilité d’exécution de code après compromission d’un compte administrateur.
La documentation WordPress recommande cette option dans son guide Editing Files. Elle ne bloque pas les modifications via SFTP, déploiement ou accès au système.
Vérifiez que l’équipe possède une méthode maintenable pour corriger et déployer le code.
Comprendre DISALLOW_FILE_MODS
DISALLOW_FILE_MODS va plus loin : il bloque aussi installation et mise à jour depuis l’administration et implique la désactivation de l’éditeur. Utilisez-le seulement si un pipeline ou une équipe assume réellement les mises à jour.
Sur un site sans processus externe, cette constante peut laisser des composants obsolètes. La sécurité gagnée sur l’écriture peut être perdue par l’absence de correctifs.
Documentez qui met à jour, quand et comment revenir.
Exiger HTTPS pour l’administration
FORCE_SSL_ADMIN demande HTTPS pour connexions et administration. Il suppose que certificat, proxy et détection HTTPS sont correctement configurés.
Testez connexion, cookies, URL publique, proxy et redirections. Une boucle indique souvent une incohérence d’en-têtes ou de configuration, pas une raison de désactiver durablement HTTPS.
Le guide HTTPS WordPress couvre certificat, redirections et contenu mixte.
Configurer le diagnostic
En production, n’affichez pas les erreurs PHP aux visiteurs. Pour un diagnostic limité, activez la journalisation selon la documentation, reproduisez le problème, collectez le minimum puis désactivez ou réduisez le niveau.
Les journaux peuvent contenir chemins, requêtes, e-mails ou jetons. Protégez leur accès, définissez une rétention et masquez les données avant partage.
Ne laissez pas SCRIPT_DEBUG ou une configuration de développement active sans raison.
Déclarer le type d’environnement
WP_ENVIRONMENT_TYPE peut distinguer local, development, staging et production. Le code peut adapter un comportement, mais cette valeur ne sécurise pas automatiquement le staging ni ne désactive chaque intégration.
Vérifiez le résultat retourné par WordPress et documentez qui utilise la valeur. Une chaîne invalide peut produire un comportement inattendu.
Le guide staging WordPress détaille les protections complémentaires.
Gérer WP-Cron avec prudence
Ne définissez DISABLE_WP_CRON que lorsqu’un autre déclencheur est configuré, testé et surveillé. La constante change l’occasion d’exécution, pas l’existence des événements.
Une copie de configuration entre environnements peut désactiver les tâches sur un site qui n’a pas de planificateur externe. Documentez la dépendance.
Le diagnostic complet est expliqué dans WP-Cron ne fonctionne pas.
Éviter les réglages de mémoire universels
Augmenter une limite peut masquer une fuite ou un plugin inefficace. Mesurez le besoin, vérifiez la limite effective imposée par PHP ou l’hébergement et testez la stabilité.
Une valeur très élevée ne crée pas de capacité physique et peut aggraver une saturation sous concurrence. Corrigez la cause lorsque la consommation est anormale.
Ne publiez pas la mémoire réelle de l’environnement comme promesse.
Protéger le préfixe des tables
Un préfixe non standard peut éviter certaines suppositions simplistes, mais il n’est pas une frontière de sécurité. Les requêtes WordPress connaissent le préfixe configuré et une injection SQL réussie peut souvent le découvrir.
Changer le préfixe d’un site existant touche tables et métadonnées ; ne le faites pas comme geste cosmétique. Sauvegardez, testez et utilisez une procédure spécialisée si une migration l’exige.
Concentrez l’effort sur mises à jour, requêtes préparées et privilèges.
Séparer les environnements
Ne copiez pas automatiquement les mêmes secrets, URL et comportements de sortie vers staging. Chargez une configuration adaptée, neutralisez e-mails et paiements et protégez l’accès.
Évitez les conditions fragiles basées uniquement sur le nom d’hôte. Utilisez une déclaration d’environnement maintenue et des secrets propres à chaque contexte.
Testez la configuration finale, pas un fichier générique différent de la production.
Valider après chaque modification
Vérifiez syntaxe PHP, accueil, administration, connexion, permaliens, tâches, mises à jour et fonctions métier. Consultez les erreurs immédiatement et revenez au fichier précédent si nécessaire.
Appliquez une modification à la fois avec revue. Une série de constantes copiées empêche d’attribuer la régression.
Conservez un diff privé sans valeurs secrètes.
Les erreurs à éviter
- Publier un
wp-config.php« anonymisé » mais encore identifiable. - Laisser une copie
.bakdans le webroot. - Appliquer des permissions numériques sans comprendre le propriétaire.
- Activer le debug visible en production.
- Bloquer les mises à jour sans pipeline de remplacement.
- Utiliser un préfixe comme mesure principale de sécurité.
- Désactiver WP-Cron avant de tester le déclencheur externe.
- copier les secrets de production sur staging.
Checklist sécuriser wp-config.php
- [ ] Une copie de retour protégée existe.
- [ ] Propriétaire et permissions sont adaptés à l’architecture.
- [ ] L’accès HTTP et les fichiers de sauvegarde sont bloqués.
- [ ] Les secrets sont hors des canaux publics et des dépôts.
- [ ] Les clés peuvent être renouvelées.
- [ ] L’éditeur intégré est désactivé si le flux le permet.
- [ ] Les mises à jour restent prises en charge.
- [ ] Le diagnostic n’est pas affiché publiquement.
- [ ] Chaque environnement possède sa configuration.
- [ ] Chaque constante est testée et documentée.
Conclusion
Pour sécuriser wp-config.php, réduisez lecture et écriture, protégez les secrets, contrôlez le diagnostic et n’activez que les comportements assumés par l’exploitation. Le fichier doit rester simple, explicite et récupérable.
La meilleure constante ne compense pas des composants obsolètes ou des comptes trop puissants. Pour relier configuration, maintenance et plateforme, consultez choisir un hébergement WordPress.