Comment sécuriser wp-config.php

wp-config.php est le fichier le plus sensible d'une installation WordPress. Il contient en clair le nom, l'utilisateur, le mot de passe et l'hôte de la base de données, ainsi que les clés d'authentification et les sels que WordPress utilise pour signer les cookies de connexion. Quiconque peut le lire peut lire toute votre base de données. Il mérite une protection plus stricte que le schéma 644 et 755 appliqué au reste.

Resserrer ses permissions

La valeur par défaut est généralement 644, ce qui permet à tous les utilisateurs du serveur de lire le fichier. Sur un hébergement mutualisé, « tous les utilisateurs » n'est pas une hypothèse théorique. Resserrez :

• 600 (le propriétaire lit et écrit) est le choix courant le plus strict. chmod 600 wp-config.php
• 640 (le propriétaire lit et écrit, le groupe lit) est nécessaire chez certains hébergeurs où le serveur web s'exécute sous le groupe du fichier plutôt que sous son propriétaire.
• 440 ou 400 (lecture seule) fonctionne aussi et évite que le fichier soit modifié par accident ou par un script. Il faut alors l'assouplir brièvement pour le modifier.

Le test est simple : appliquez la valeur la plus stricte, puis chargez le site. S'il affiche une erreur de base de données ou une page blanche, PHP n'a pas pu lire le fichier : passez alors à 640. Ne sautez pas à 777, qui rend le fichier modifiable par tout le monde. Le guide des permissions de fichiers traite le reste du site.

Le déplacer au-dessus de la racine web

WordPress cherche wp-config.php d'abord dans son propre dossier, puis un dossier au-dessus. Si vous remontez le fichier d'un niveau, il n'est plus dans le répertoire publié par le serveur web. Même si une erreur de configuration servait un jour le code source PHP en texte au lieu de l'exécuter, le fichier ne s'y trouverait pas.

Cela fonctionne quand WordPress est à la racine web et que rien d'autre dans le dossier parent n'est une installation WordPress. Quelques hébergeurs mutualisés restrictifs bloquent l'accès en dehors de la racine web : laissez alors le fichier en place et comptez sur les permissions et sur la règle serveur ci-dessous.

Bloquer les requêtes directes au niveau du serveur web

Sur Apache, une règle dans .htaccess peut refuser toute requête vers le fichier par URL. Ajoutez ceci en haut du fichier à la racine de votre site :

<Files wp-config.php> Require all denied </Files>

Sur Nginx, l'équivalent est un bloc location = /wp-config.php qui renvoie une 404 ou refuse la requête. Le support de votre hébergeur peut l'ajouter si vous ne gérez pas la configuration du serveur.

Renouveler les clés secrètes après un incident

Le fichier contient aussi huit clés d'authentification et sels. WordPress les utilise pour signer les cookies de connexion. Si vous soupçonnez qu'une personne a eu accès, générez un nouveau jeu et remplacez les anciennes valeurs. Toutes les sessions existantes sont alors invalidées, ce qui déconnecte toute personne détenant un cookie volé, sans que personne n'ait à changer de mot de passe. Avec WP-CLI, c'est une seule commande : wp config shuffle-salts. Sinon, utilisez le générateur officiel de clés secrètes de WordPress et collez le résultat.

Quelques réglages sûrs à ajouter

• Désactiver l'éditeur de fichiers intégré. define( 'DISALLOW_FILE_EDIT', true ); retire les éditeurs de thèmes et de plugins de wp-admin, de sorte qu'une connexion administrateur volée ne puisse pas servir à modifier du PHP depuis le navigateur.
• Garder le débogage désactivé en production. WP_DEBUG doit être à false sur un site en ligne. Si vous avez besoin de journaux, envoyez-les dans un fichier avec WP_DEBUG_LOG et mettez WP_DEBUG_DISPLAY à false, car les erreurs affichées à l'écran peuvent révéler des chemins de fichiers.
• Forcer HTTPS pour les connexions. define( 'FORCE_SSL_ADMIN', true ); maintient l'administration et la connexion en HTTPS.
• Ne donner à l'utilisateur de la base que ce dont il a besoin. Il ne doit avoir accès qu'à la base de ce site, et son mot de passe doit être unique, comme le recommande la checklist de sécurité.

Comment le tester

Demandez le fichier comme le ferait un inconnu. Lancez curl -I https://votresite.example/wp-config.php. Vous voulez une 403 ou une 404, ou une 200 avec un corps vide (PHP s'est exécuté et n'a rien affiché). Si vous voyez un jour le texte du fichier, arrêtez-vous et changez immédiatement le mot de passe de la base de données et les clés secrètes. Vérifiez ensuite les permissions du fichier avec ls -l wp-config.php et confirmez que le site se charge toujours.

Ce qu'il ne faut pas faire

N'assouplissez pas les permissions du fichier pour « réparer » un plugin qui dit ne pas pouvoir le lire. C'est presque toujours un problème ailleurs, et 777 sur le fichier qui contient le mot de passe de votre base est l'un des pires endroits pour se tromper. Ne laissez pas non plus de copies dans des dossiers publics. Un wp-config.php.bak ou wp-config.old oublié à la racine du site ou dans uploads/ est une fuite fréquente de ce fichier, car le serveur le livre en texte brut. Supprimez les sauvegardes ou gardez-les hors de la racine web.