Sécuriser wp-config.php : 10 réglages à vérifier

wp-config.php contient le mot de passe de votre base de données, les clés qui signent chaque cookie de connexion et les interrupteurs qui décident si les erreurs s'affichent aux visiteurs. La plupart des propriétaires de site ne l'ont jamais ouvert. Ce guide pour sécuriser wp-config.php est un audit en dix points de ce seul fichier. Pour chaque contrôle, vous avez la ligne exacte, la valeur à utiliser en production, la façon de vérifier et ce que le réglage ne protège pas.

Ce que contrôle wp-config.php, et comment le modifier sans écran blanc

Le fichier contient trois types d'éléments. D'abord, les identifiants de la base de données. Ensuite, huit clés et sels (salts) de sécurité. Enfin, des constantes qui modifient le comportement de WordPress. Quiconque peut lire le fichier peut se connecter à votre base de données. Quiconque peut y écrire peut exécuter du code à chaque chargement de page.

C'est aussi le fichier le plus facile à casser. Un simple point-virgule manquant provoque un écran blanc ou une erreur fatale chez tous les visiteurs. Suivez cette procédure à chaque modification :

1. Téléchargez sur votre ordinateur une copie du fichier actuel.
2. Modifiez-le via SFTP ou SSH, pas dans un gestionnaire de fichiers en ligne ni avec une extension.
3. Si vous avez un accès shell, lancez php -l wp-config.php. La commande doit afficher « No syntax errors detected ».
4. Rechargez le site public et /wp-admin/ dans une fenêtre de navigation privée.
5. Si quelque chose ne fonctionne plus, renvoyez votre copie sur le serveur. Corrigez ensuite la modification à tête reposée.
6. Si tout fonctionne, supprimez les copies temporaires créées sur le serveur (comme wp-config.php.bak). Gardez la copie sur votre ordinateur.

L'emplacement compte. Vers la fin du fichier, vous trouverez le commentaire /* That's all, stop editing! Happy publishing. */, suivi de require_once ABSPATH . 'wp-settings.php';. Les constantes définies après cette ligne arrivent trop tard pour la plupart des réglages. Placez chaque nouveau define() au-dessus du commentaire. La référence officielle est la page wp-config.php de la documentation développeur WordPress.

Secrets : identifiants de base de données, clés et sels de sécurité uniques

Contrôle 1 : identifiants de la base de données. DB_USER doit être un utilisateur de base de données qui n'existe que pour ce site, avec un long mot de passe aléatoire. Si trois sites partagent le même utilisateur, la fuite d'un seul expose les trois. N'y réutilisez jamais le mot de passe de votre panneau d'hébergement. Ce contrôle ne sert à rien si l'attaquant exécute déjà du code sur le serveur, puisqu'il peut de toute façon lire le fichier.

Contrôle 2 : clés et sels. Il y en a huit : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et les quatre constantes _SALT correspondantes. Elles doivent être longues, aléatoires et propres à ce site. Si l'une d'elles affiche encore put your unique phrase here, corrigez-la aujourd'hui. Vous pouvez générer un nouveau jeu sur api.wordpress.org/secret-key/1.1/salt/ et le coller à la place de l'ancien bloc. Avec WP-CLI, une seule commande suffit :

wp config shuffle-salts

Renouvelez les sels après un piratage, quand un administrateur ou une agence ayant accès aux fichiers s'en va, ou si le fichier a un jour été exposé.

Après une compromission, le renouvellement de ces secrets n'est qu'une étape d'un nettoyage plus large. Consultez la suppression d'un malware WordPress pour l'ordre complet des opérations.

Débogage en production : WP_DEBUG, WP_DEBUG_DISPLAY et WP_DEBUG_LOG

Contrôle 3 : WP_DEBUG. Sur un site en ligne, cette valeur doit être false. Les erreurs affichées révèlent des chemins serveur, des noms d'extensions et parfois des fragments de requêtes. Un attaquant peut s'en servir pour choisir sa cible.

define( 'WP_DEBUG', false );

Mettre WP_DEBUG à false ne désactive pas le réglage display_errors propre à PHP. S'il est activé chez votre hébergeur, des avertissements peuvent encore s'afficher dans la page. Demandez à l'hébergeur, ou vérifiez la configuration PHP si vous gérez votre propre serveur.

Contrôle 4 : si vous avez besoin de journaux, cachez-les et déplacez-les. Il arrive qu'il faille déboguer en production. Dans ce cas, n'affichez jamais les erreurs dans la page et n'utilisez pas l'emplacement de journal par défaut. WP_DEBUG_LOG à true écrit dans wp-content/debug.log, souvent téléchargeable publiquement. Indiquez plutôt un chemin de fichier situé en dehors de la racine web :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Le répertoire doit exister et être accessible en écriture à l'utilisateur PHP. Vérifiez ensuite qu'aucun ancien journal n'est resté public :

curl -I https://example.com/wp-content/debug.log

Vous voulez obtenir 403 ou 404. Un 200 signifie que n'importe qui peut lire le journal. Supprimez-le.

Les journaux contiennent souvent des adresses e-mail, des adresses IP et des données de formulaires, c'est-à-dire des données à caractère personnel. Désactivez la journalisation dès que vous avez terminé, puis supprimez ou faites tourner les anciens fichiers. Chaque constante est détaillée dans la documentation WordPress sur le débogage.

HTTPS et environnement : FORCE_SSL_ADMIN et WP_ENVIRONMENT_TYPE

Contrôle 5 : FORCE_SSL_ADMIN. Ce réglage maintient la page de connexion, le tableau de bord et les cookies d'administration en HTTPS :

define( 'FORCE_SSL_ADMIN', true );

Il ne couvre que l'administration et les connexions. Il ne remplace pas une redirection HTTP vers HTTPS sur l'ensemble du site au niveau du serveur, et ce n'est pas HSTS.

Contrôle 6 : WP_ENVIRONMENT_TYPE. Ce réglage indique à WordPress et aux extensions sur quel type de site ils tournent. Les valeurs possibles sont production, staging, development et local. La valeur par défaut est production.

define( 'WP_ENVIRONMENT_TYPE', 'production' );

Le réglage a de vrais effets. Dans le cœur de WordPress, un environnement development active WP_DEBUG si vous ne l'avez pas défini vous-même. Certaines extensions et certains hébergeurs lisent la valeur pour bloquer l'envoi d'e-mails ou modifier le cache sur les sites hors production. L'enjeu principal reste l'étiquetage. Un site de préproduction contient généralement une copie complète des données réelles des clients et des commandes. Marquez-le staging et protégez-le par une authentification HTTP ou une restriction par IP. Supprimez-le à la fin du projet. Un sous-domaine de préproduction oublié, avec la base clients de l'an dernier, est une source de fuites très courante.

Éditeur de fichiers et modifications : DISALLOW_FILE_EDIT et DISALLOW_FILE_MODS

Contrôle 7 : ajoutez cette ligne à chaque site :

define( 'DISALLOW_FILE_EDIT', true );

Elle retire du tableau de bord les éditeurs de fichiers des thèmes et des extensions. Un identifiant d'administrateur volé ne peut alors plus être transformé en exécution de code en quelques clics. Elle n'arrête pas un attaquant capable de téléverser une extension.

Contrôle 8 : DISALLOW_FILE_MODS va plus loin. Il bloque aussi l'installation et la mise à jour des extensions et des thèmes depuis le tableau de bord, et il désactive les mises à jour automatiques en arrière-plan. Activez-le seulement quand vous disposez d'un autre circuit de mise à jour : WP-CLI, une chaîne de déploiement ou des mises à jour gérées par l'hébergeur. Sinon, vous venez de figer le site sur les versions vulnérables d'aujourd'hui. Ces deux réglages et le processus de mise à jour sont traités dans DISALLOW_FILE_EDIT : désactiver l'éditeur de fichiers de WordPress.

Permissions, emplacement et copies oubliées de wp-config.php

Contrôle 9 : permissions. La bonne valeur dépend de l'utilisateur sous lequel PHP s'exécute :

• 400 ou 440 : à utiliser quand le propriétaire du fichier n'est pas l'utilisateur PHP. Le groupe doit inclure l'utilisateur PHP, qui n'a alors besoin que de la lecture.
• 600 : à utiliser quand PHP s'exécute sous le compte propriétaire du fichier, ce qui est courant avec un pool PHP-FPM par compte.

Évitez 644 sur un hébergement mutualisé : d'autres comptes du même serveur pourraient lire le fichier. N'utilisez jamais 777.

ls -l wp-config.php
chmod 440 wp-config.php

Pour la propriété et les permissions sur le reste de l'installation, consultez les web shells et les permissions de fichiers.

Déplacer le fichier un répertoire au-dessus de la racine web est autorisé. WordPress le cherche automatiquement à cet endroit quand le dossier parent ne contient pas sa propre installation WordPress. Le gain est faible : il ne joue que si PHP cesse de s'exécuter et que le serveur renvoie les fichiers .php en texte brut. Faites-le si c'est simple, mais ne le comptez pas comme une protection.

Contrôle 10 : copies oubliées. C'est le risque le plus important et le plus fréquent. Des fichiers comme wp-config.php.bak, wp-config.php.old, wp-config.php.save, wp-config.php~ ou un fichier d'échange d'éditeur comme .wp-config.php.swp ne se terminent pas par .php. Le serveur web peut les servir en texte brut, mot de passe de la base de données compris. Cherchez-les :

find /var/www/example -name '*wp-config*' -type f

Seuls wp-config.php et l'inoffensif wp-config-sample.php doivent subsister. Supprimez le reste. Les renommer ne sert à rien. Si une copie était accessible depuis le web, renouvelez aussi le mot de passe de la base de données et les sels.

Les 10 contrôles de wp-config.php en un tableau

Un résultat propre ici ne dit rien des extensions vulnérables, des mots de passe d'administrateur faibles ou d'une version de PHP obsolète. Pour cela, utilisez la liste de contrôle de sécurité WordPress.

L'extension Security Audit & Compliance de secaudit.eu comprend une analyse de durcissement et de configuration, et détecte les secrets et fichiers exposés, comme les sauvegardes oubliées. Elle propose aussi une option pour désactiver les éditeurs de fichiers du tableau de bord → secaudit.eu

Prochaine étape : téléchargez dès maintenant une copie de wp-config.php et lancez la commande find pour repérer les copies oubliées. Cela prend deux minutes et couvre l'exposition la plus souvent négligée.

FAQ

Changer les sels va-t-il casser mon site ?

Non. Les contenus, les réglages et les mots de passe restent intacts. Chaque utilisateur connecté est déconnecté et doit se reconnecter : prévenez donc d'abord vos rédacteurs et les clients de votre boutique.

Dois-je changer le préfixe des tables sur un site existant ?

En général, non. Un préfixe personnalisé apporte peu de protection réelle, et le modifier sur un site en production oblige à renommer les tables et à mettre à jour des entrées dans les tables options et usermeta. Une erreur peut verrouiller tous les utilisateurs. Laissez-le tel quel, sauf si vous refaites le site de toute façon.

Une extension peut-elle gérer wp-config.php à ma place ?

Certaines le peuvent. Mais une extension capable d'écrire dans wp-config.php est elle-même un risque : une faille dans cette extension devient un accès en écriture à votre fichier le plus sensible. Préférez les modifications manuelles via SFTP ou SSH, et gardez une copie de la dernière version fonctionnelle.