On sécurise un site WordPress en changeant le mot de passe admin et en installant un plugin de sécurité. wp-config.php et les permissions de fichiers restent la partie qu’on ne touche jamais, celle qui contient pourtant les identifiants de la base de données et qui décide qui a le droit d’écrire dans les dossiers. WP 6.x casse régulièrement des thèmes custom, on passe déjà son temps à patcher pour les clients. Personne ne vérifie qui peut encore modifier wp-content pendant ce temps. Ce guide couvre le durcissement de wp-config.php (clés secrètes, constantes de sécurité) puis les permissions correctes sur fichiers et dossiers, dans l’ordre où elles se configurent. Comptez 30 minutes en SSH ou via le gestionnaire de fichiers de l’hébergeur, sauvegarde comprise.
Ce que wp-config.php protège réellement
wp-config.php centralise les identifiants de connexion à la base de données ainsi que 8 clés secrètes : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs 4 variantes SALT. Ces clés chiffrent les cookies de session et les jetons nonce de chaque utilisateur connecté. Un attaquant qui lit ce fichier obtient l’accès direct à la base et peut forger des cookies de session valides, sans jamais passer par le formulaire de connexion. C’est le fichier le plus sensible d’une installation WordPress, avant même les identifiants FTP.
Régénérer les clés secrètes avec le générateur officiel
Les clés livrées par défaut lors d’une installation manuelle sont parfois copiées d’un tutoriel à l’autre sans être régénérées. Ouvrez le générateur officiel WordPress, copiez le bloc de 8 constantes retourné, puis remplacez la section correspondante dans wp-config.php. Régénérer ces clés invalide immédiatement toutes les sessions actives : chaque utilisateur connecté, y compris vous-même, devra se reconnecter. Faites-le hors des heures d’affluence côté client, jamais en pleine campagne d’emailing programmée depuis le site. Sauvegardez wp-config.php avant toute modification, un fichier corrompu par une copie incomplète bloque l’accès au site entier.
Verrouiller wp-config.php avec les bonnes constantes de sécurité
4 constantes ajoutées dans wp-config.php réduisent la surface d’attaque sans toucher au serveur. Elles se placent juste avant la ligne /* That’s all, stop editing! */.
- define(‘DISALLOW_FILE_EDIT’, true); bloque l’éditeur de thèmes et de plugins intégré à l’administration, pour tous les comptes y compris les administrateurs. Une extension compromise ne peut plus injecter du code PHP via cette porte.
- define(‘DISALLOW_FILE_MODS’, true); va plus loin en bloquant l’installation et la mise à jour de plugins ou thèmes depuis l’admin (la suppression est verrouillée avec). Utile sur les sites gérés en déploiement contrôlé. Elle coupe aussi les mises à jour automatiques de sécurité. Sur un parc de sites clients, mieux vaut coupler cette constante à un vrai suivi planifié des mises à jour plutôt que de la laisser geler le site indéfiniment.
- define(‘FORCE_SSL_ADMIN’, true); force le chiffrement TLS sur toute l’administration, y compris l’écran de connexion, même si le reste du site tolère encore le HTTP.
- define(‘WP_DEBUG’, false); en production, avec WP_DEBUG_LOG pointé vers un fichier hors de la racine web s’il faut garder les traces. Un debug.log accessible publiquement révèle souvent les chemins serveur et les versions de plugins.
« 57% des vulnérabilités remontées au premier semestre 2025 ne nécessitaient aucune authentification pour être exploitées. » (Patchstack, 2025 Mid-Year Vulnerability Report)
Ce chiffre, tiré des failles effectivement enregistrées sous CVE, change la lecture des 4 constantes ci-dessus. Un compte admin volé, elles n’y changent rien : leur rôle est de fermer les portes qu’une faille anonyme dans une extension peut ouvrir sans le moindre mot de passe.
Déplacer wp-config.php hors de la racine web
Déplacer wp-config.php un niveau au-dessus du dossier public_html (ou www) coupe le fichier de toute exposition directe via une URL, sans modifier une seule ligne de code. WordPress le retrouve automatiquement au démarrage : il cherche wp-config.php d’abord à la racine de l’installation, puis, s’il ne l’y trouve pas, dans le répertoire immédiatement parent, un comportement documenté dans le Advanced Administration Handbook. La limite existe : certains plugins de migration ou de sauvegarde qui écrivent dans wp-config.php perdent l’accès au fichier une fois déplacé. Il faut alors leur indiquer le chemin manuellement. Testez la connexion admin juste après le déplacement.
Fixer les permissions correctes sur fichiers et dossiers
La règle qui fonctionne sur la majorité des configurations Apache et Nginx : dossiers en 755, fichiers en 644. wp-config.php descend à 640 si PHP tourne via un groupe distinct du propriétaire (cas fréquent en PHP-FPM) ou à 600 si le propriétaire du fichier exécute directement PHP. Jamais de permission 777, sur aucun fichier ni dossier, quelle que soit l’urgence du moment. Ces réglages comptent : 96% des vulnérabilités WordPress recensées se concentrent dans les extensions, sur un total de 7 966 failles nouvelles en 2024, en hausse de 34% par rapport à 2023, d’après le rapport State of WordPress Security 2025 de Patchstack. Les permissions décident ce qu’une extension compromise peut réellement faire une fois la faille exploitée : lire un fichier ou, pire, écrire dedans. Les permissions par défaut varient selon l’hébergeur. Beaucoup héritent d’une installation en 755 partout, y compris sur wp-config.php.
Depuis une connexion SSH, à la racine WordPress :
find . -type d -exec chmod 755 {} \;find . -type f -exec chmod 644 {} \;chmod 640 wp-config.php
Vérifiez ensuite le propriétaire des fichiers avec ls -la : il doit correspondre à l’utilisateur système sous lequel PHP s’exécute. Un compte root ou un compte FTP générique partagé entre plusieurs sites n’est jamais la bonne réponse ici. Le même principe de moindre privilège s’applique aux comptes qui gèrent le site : un réglage précis des rôles utilisateurs restreint qui peut modifier quoi dans l’admin, en complément des permissions système. Sur un hébergement managé, ces réglages sont parfois déjà appliqués et verrouillés par la configuration serveur, ce qui n’empêche pas de les vérifier à la main sur les mutualisés classiques ou les VPS auto-administrés. La faille exploitée dans une extension prend rarement la forme d’une écriture directe de fichier : la désérialisation d’objet PHP mal filtrée reste un vecteur fréquent. Elle contourne les permissions restrictives si le processus PHP lui-même a les droits d’écriture.
wp-content writable, le piège qui annule tout le reste
Le dossier uploads/ a besoin d’écriture pour accepter les médias importés depuis la bibliothèque. Les dossiers plugins/ et themes/, eux, n’ont pas besoin d’être group-writable en permanence : ils ne le deviennent que le temps d’une mise à jour, via les identifiants FTP ou SSH stockés dans wp-config.php. Beaucoup d’hébergeurs laissent pourtant wp-content entier en 775 par défaut, pour que les mises à jour automatiques passent sans configuration FTP à saisir. Résultat : un plugin vulnérable qui autorise l’écriture d’un fichier arbitraire, comme dans les cas d’injection zero-day documentés sur les extensions WordPress, retrouve exactement le dossier ouvert dont il a besoin pour déposer un webshell. wp-config.php verrouillé à 600 ne sert plus à rien si wp-content reste grand ouvert juste à côté.
Vérifier que le durcissement n’a rien cassé
Une erreur 500 juste après un chmod trop restrictif est le symptôme le plus courant. Elle vient presque toujours d’un fichier passé en 600 alors que le processus PHP tourne sous un utilisateur différent du propriétaire. Consultez le journal d’erreurs du serveur, il nomme directement le fichier incriminé. Depuis WP-CLI, la commande wp core verify-checksums compare l’installation aux fichiers officiels et signale toute modification suspecte, une vérification utile après chaque campagne de durcissement sur un parc de sites clients. Testez ensuite une mise à jour de plugin réelle. Un échec silencieux pointe généralement vers DISALLOW_FILE_MODS ou vers une permission trop stricte sur wp-content. Vérifiez enfin l’accès direct au fichier : une requête sur https://votredomaine.fr/wp-config.php doit renvoyer une erreur 403 ou 404, jamais le contenu du fichier.
wp-config.php verrouillé et permissions correctes couvrent le fichier de configuration et le système de fichiers. Ils ne couvrent ni le pare-feu applicatif (WAF) ni la limitation des tentatives de connexion sur wp-login.php. Restent aussi la vérification que les sauvegardes se restaurent réellement et le monitoring des accès SSH sur le serveur qui héberge le tout. Ce sont les chantiers suivants sur un site WordPress qui gère des données sensibles.
