Comment sécuriser le journal de débogage de WordPress

Lorsque le débogage de WordPress est activé, les erreurs et avertissements sont écrits dans un fichier de journal à /wp-content/debug.log. C'est extrêmement utile pendant le développement. Sur un site en production, en revanche, un journal de débogage accessible publiquement représente un risque de sécurité sérieux. Toute personne connaissant l'URL peut le lire, et il contient souvent bien plus d'informations sensibles que la plupart des propriétaires de sites ne le pensent.

Ce que contient le journal de débogage

Le fichier debug.log n'est pas seulement une liste d'avertissements PHP. Selon la configuration de votre site et les extensions que vous utilisez, il peut contenir :

• Erreurs et avertissements PHP : Ils incluent des chemins de fichiers, des numéros de ligne et des noms de fonctions. Un attaquant peut utiliser ces informations pour cartographier la structure de répertoires de votre serveur et identifier du code vulnérable.
• Erreurs de requêtes de base de données : Les requêtes en échec contiennent parfois des noms de tables, des noms de colonnes et même des fragments des données interrogées. Cela donne aux attaquants un aperçu de votre schéma de base de données.
• Erreurs d'extensions et de thèmes avec traces de pile : Les traces de pile révèlent quelles extensions vous utilisez, leurs versions et comment elles interagissent. C'est précieux pour planifier des attaques ciblées contre des vulnérabilités d'extensions connues.
• Clés API et identifiants : Des extensions mal écrites enregistrent parfois des réponses d'API ou des erreurs de connexion qui contiennent des jetons d'authentification, des clés API ou même des mots de passe en clair.
• Données utilisateur et adresses e-mail : Les erreurs liées à l'inscription des utilisateurs, aux soumissions de formulaires ou à l'envoi d'e-mails peuvent inclure des données personnelles comme des noms, des adresses e-mail et des entrées de formulaire.
• Chemins du système de fichiers : Chaque erreur PHP inclut le chemin complet du serveur vers le fichier où elle s'est produite. Cela révèle votre structure de répertoires d'hébergement, votre nom d'utilisateur et parfois votre fournisseur d'hébergement.

Pourquoi le journal de débogage est accessible publiquement

Par défaut, WordPress stocke debug.log dans le répertoire wp-content. Ce répertoire est servi par votre serveur web comme n'importe quel autre dossier de votre installation WordPress. Sauf si vous avez spécifiquement bloqué l'accès, n'importe qui peut taper https://votresite.com/wp-content/debug.log dans un navigateur et lire le fichier.

De nombreux fournisseurs d'hébergement ne bloquent pas ce chemin par défaut. Et comme le fichier grandit au fil du temps sans rotation automatique, il peut accumuler des mois voire des années de données d'erreurs sensibles.

Comment les attaquants trouvent les journaux de débogage

Les scanners automatisés vérifient systématiquement /wp-content/debug.log sur chaque site WordPress qu'ils rencontrent. C'est l'un des premiers chemins testés par les outils d'analyse de sécurité. Certains attaquants vérifient également des variations courantes :

• /wp-content/debug.log (emplacement par défaut)
• /debug.log (parfois mal configuré)
• /wp-content/uploads/debug.log (autre mauvaise configuration courante)
• /error_log ou /error.log (noms génériques de journaux d'erreurs)

Ces analyses sont peu coûteuses, rapides et entièrement automatisées. Si votre journal de débogage est accessible, il sera trouvé.

Bloquer l'accès avec .htaccess (Apache)

Si votre serveur utilise Apache, ajoutez cette règle au fichier .htaccess dans votre répertoire wp-content :

<Files debug.log>
    Order allow,deny
    Deny from all
</Files>

Cela indique à Apache de refuser toutes les requêtes HTTP pour le fichier debug.log. Le fichier existe toujours sur le disque et PHP peut toujours y écrire, mais personne ne peut le télécharger via un navigateur. Si vous souhaitez bloquer tous les fichiers journaux par précaution, vous pouvez utiliser une règle plus large :

<FilesMatch ".(log|txt)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Bloquer l'accès avec Nginx

Pour les serveurs Nginx, ajoutez ce bloc location à votre configuration de serveur :

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Renvoyer un 404 plutôt qu'un 403 est un choix délibéré. Une réponse 403 (Interdit) indique à un attaquant que le fichier existe mais est protégé. Un 404 (Non trouvé) ne révèle rien. Après avoir ajouté cette règle, rechargez la configuration Nginx avec sudo nginx -s reload.

Déplacer le fichier journal en dehors de la racine web

L'approche la plus sûre consiste à stocker le journal de débogage dans un répertoire que votre serveur web ne peut pas servir du tout. Dans votre wp-config.php, définissez la constante WP_DEBUG_LOG sur un chemin absolu en dehors de votre racine web :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/youruser/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

Le répertoire /home/youruser/logs/ doit exister et être accessible en écriture par le processus du serveur web. Définir WP_DEBUG_DISPLAY sur false est tout aussi important : cela empêche l'affichage des erreurs PHP directement sur vos pages, où les visiteurs (et les attaquants) pourraient les voir.

Désactiver le mode débogage sur les sites de production

Sur un site en production, le débogage devrait presque toujours être désactivé. Il y a rarement une bonne raison de le laisser activé en permanence. Définissez ces valeurs dans wp-config.php :

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Si vous devez déboguer un problème en production, activez le mode débogage temporairement, reproduisez le problème, vérifiez le journal, puis désactivez-le immédiatement. Ne laissez jamais le débogage activé « au cas où ». Le risque ne vaut pas la commodité.

Surveiller la taille du fichier journal de débogage

Si vous gardez le débogage activé sur un site de préproduction ou de développement, surveillez la taille du journal de débogage. Sans rotation des journaux, il peut atteindre des centaines de mégaoctets et finir par remplir votre disque. Envisagez de configurer une tâche cron pour le faire tourner ou le tronquer :

# Faire tourner debug.log chaque semaine, garder 4 sauvegardes
# A ajouter dans /etc/logrotate.d/wp-debug
/home/youruser/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Que faire si des données sensibles ont déjà été exposées

Si votre journal de débogage était accessible publiquement et contenait des informations sensibles, prenez ces mesures immédiatement :

• Supprimez le fichier de journal de débogage : Retirez-le immédiatement du serveur.
• Renouvelez toutes les clés API et identifiants : Toute clé API, mot de passe ou jeton apparaissant dans le journal doit être considéré comme compromis. Régénérez-les.
• Changez les mots de passe de la base de données : Si des erreurs de connexion à la base de données ont été enregistrées, les identifiants peuvent avoir été exposés.
• Vérifiez les accès non autorisés : Examinez les journaux d'accès de votre serveur pour les requêtes vers debug.log. Si quelqu'un l'a téléchargé, évaluez quelles informations il a obtenues.
• Notifiez les utilisateurs concernés : Si des données personnelles (e-mails, noms, soumissions de formulaires) ont été enregistrées, vous pouvez avoir une obligation RGPD ou de confidentialité de notifier les personnes concernées.

Vérifier avec InspectWP

InspectWP vérifie si /wp-content/debug.log est accessible publiquement sur votre site. Après avoir sécurisé le fichier (en bloquant l'accès, en le déplaçant ou en désactivant le mode débogage), lancez une nouvelle analyse InspectWP. La section sécurité du rapport confirmera si le fichier est toujours accessible. Si l'avertissement persiste, videz les caches côté serveur et vérifiez que vos règles .htaccess ou Nginx s'appliquent au bon répertoire.