Le fichier wp-config.php est le premier fichier que je consulte quand un client me confie un site WordPress existant. C’est là que se joue une grande partie de la sécurité de base : connexion à la base de données, clés de chiffrement des cookies, et une poignée de constantes qui changent radicalement la surface d’attaque du site. Pourtant, la plupart des installations gardent la configuration par défaut, celle générée automatiquement par l’assistant d’installation.
Ce n’est pas une fatalité. En quelques minutes, il est possible de durcir ce fichier sans toucher au thème ni aux extensions. Voici les réglages que j’applique systématiquement sur chaque nouveau projet, et pourquoi chacun compte.
Régénérer les clés secrètes et les sels
WordPress utilise huit constantes pour signer et chiffrer les cookies d’authentification : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs équivalents _SALT. Elles servent à garantir qu’un cookie de session ne peut pas être forgé par un tiers, même s’il devine ou vole des informations sur l’utilisateur.
Le générateur officiel à l’adresse api.wordpress.org/secret-key/1.1/salt/ produit un jeu de clés aléatoires prêtes à coller dans wp-config.php. Je recommande de les régénérer dans ces cas précis :
- À l’installation initiale, sans exception ;
- Après un incident de sécurité suspecté, même mineur ;
- Quand un collaborateur qui avait accès au fichier quitte le projet ;
- Une fois par an sur les sites sensibles, par précaution.
Régénérer les clés invalide toutes les sessions actives : tous les utilisateurs devront se reconnecter. C’est un effet secondaire acceptable, surtout comparé au bénéfice.
Désactiver WP_DEBUG et sécuriser les erreurs
La constante WP_DEBUG est indispensable en développement, mais catastrophique en production si elle reste active telle quelle : les messages d’erreur PHP peuvent révéler des chemins serveur, des noms de fonctions internes, voire des fragments de requêtes SQL. Sur un site en ligne, la configuration recommandée est la suivante :
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
Si vous avez besoin de journaliser des erreurs sur un environnement de production pour diagnostiquer un problème ponctuel, activez WP_DEBUG_LOG seul, avec WP_DEBUG_DISPLAY à false, le temps du diagnostic, puis revenez immédiatement à la configuration stricte.
Forcer SSL sur l’administration
Si votre certificat SSL est en place (et il doit l’être), la constante FORCE_SSL_ADMIN impose que toute connexion à l’administration et tout envoi d’identifiants transitent en HTTPS :
define( 'FORCE_SSL_ADMIN', true );
Cette ligne empêche qu’un identifiant ou un cookie de session parte en clair sur le réseau, un scénario particulièrement dangereux sur un Wi-Fi public. C’est un réglage qui ne casse jamais rien tant que le certificat est valide, donc il n’y a aucune raison de s’en priver.
Permissions de fichiers : 644 et 755, pas plus
Les permissions Unix mal réglées sont une porte d’entrée classique. La règle que j’applique sur tous les serveurs que j’administre :
| Élément | Permission recommandée | Commande |
|---|---|---|
| Dossiers | 755 | find . -type d -exec chmod 755 {} \; |
| Fichiers | 644 | find . -type f -exec chmod 644 {} \; |
| wp-config.php | 640 ou 600 | chmod 600 wp-config.php |
Le fichier wp-config.php mérite un traitement à part, car il contient les identifiants de la base de données en clair. Sur un hébergement mutualisé où le processus PHP tourne avec l’utilisateur du compte, 600 (lecture/écriture pour le seul propriétaire) est souvent le réglage le plus strict praticable.
Déplacer wp-config.php hors de la racine web
Peu de personnes le savent, mais WordPress cherche automatiquement wp-config.php un niveau au-dessus de la racine de l’installation si le fichier n’est pas trouvé à sa place habituelle. Cela permet de le sortir complètement du dossier servi publiquement par le serveur web :
- Placez le fichier dans le dossier parent de
public_html(ou équivalent selon votre hébergeur) ; - WordPress le détectera automatiquement, aucune configuration supplémentaire n’est nécessaire ;
- Même en cas de mauvaise configuration du serveur web exposant les fichiers PHP en clair, ce fichier reste hors d’atteinte.
Sur les hébergements mutualisés où je n’ai pas la main sur la configuration Apache ou Nginx, déplacer
wp-config.phphors de la racine web est souvent le seul filet de sécurité fiable contre une mauvaise manipulation serveur. Je le fais systématiquement, même quand tout semble déjà bien configuré.
En résumé
Aucun de ces réglages ne demande d’extension supplémentaire ni de compétence exotique : régénérer les clés secrètes, désactiver l’affichage des erreurs, forcer le SSL sur l’admin, corriger les permissions et éventuellement déplacer le fichier hors de la racine web. Pris ensemble, ils réduisent nettement la surface d’attaque d’un site WordPress, pour un coût de mise en œuvre quasi nul. C’est exactement le genre de mesures que je recommande de vérifier avant même de penser à installer une extension de sécurité.
