Scanner de logs exposés

Comment fonctionne cette vérification

Scanaris demande sept chemins où les applications les plus courantes écrivent leurs journaux quand personne ne leur dit autrement : /debug.log, /error.log, /error_log, /laravel.log, /storage/logs/laravel.log, /npm-debug.log et /wp-content/debug.log. Si l'un d'eux répond avec un fichier texte qui ressemble à un journal, et non avec la page générique de ton site, il ouvre un constat de sévérité moyenne avec le chemin. Les journaux contiennent rarement toute la base de données, d'où l'absence de criticité ; mais peu de fichiers en disent autant sur le fonctionnement interne de ton site.

Pourquoi c'est important

Un journal d'erreurs est le carnet de tout ce qui a échoué : chemins internes du serveur, noms de fichiers et de fonctions, versions exactes des bibliothèques, requêtes vers la base qui ont échoué avec leurs paramètres, adresses IP des utilisateurs, parfois des e-mails ou des jetons apparus dans une requête. Avec ça, quelqu'un qui cherche une vulnérabilité sait exactement où regarder et quelle version attaquer. Et le journal grossit : chaque jour d'exposition en dit davantage.

Pourquoi ça arrive

WordPress avec WP_DEBUG_LOG activé écrit dans wp-content/debug.log, qui est un dossier public ; c'est le cas le plus fréquent. Laravel garde ses journaux dans storage/logs, qui ne devrait pas être accessible, mais l'est quand le serveur pointe vers la racine du projet au lieu de public/. Apache en hébergement mutualisé laisse error_log à côté des fichiers du site. Et npm-debug.log apparaît quand une installation a échoué sur le serveur et que personne n'a nettoyé.

Comment corriger

• WordPress : en production, define('WP_DEBUG', false); dans wp-config.php. Si tu as besoin du journal temporairement, déplace-le hors du dossier public avec define('WP_DEBUG_LOG', '/chemin/prive/debug.log'); et supprime le fichier actuel.
• Laravel : le serveur web doit pointer vers le dossier public/ du projet, jamais vers la racine. Ainsi storage/ cesse d'être atteignable. Et APP_DEBUG=false.
• Node et autres : écris les journaux hors du répertoire servi et envoie-les à un service de journalisation si possible. Supprime les npm-debug.log et similaires du serveur.
• Bloque l'extension côté serveur comme seconde barrière. En nginx : location ~* \.log$ { deny all; }. En Apache : <FilesMatch "\.log$"> Require all denied </FilesMatch>.
• Réduis ce que tu journalises en production : niveau erreur plutôt que debug, sans vider les corps de requête complets ni les jetons.

Vérifie que c'est corrigé

for p in debug.log error.log error_log laravel.log storage/logs/laravel.log npm-debug.log wp-content/debug.log; do
  printf "%-28s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tondomaine.com/$p"
done

Attendu : 404 ou 403 partout. Si ton site est une application monopage et répond 200 avec son HTML, ce n'est pas le journal ; ouvre-le pour confirmer.

Questions fréquentes

Mon journal ne contient rien de sensible, juste des avertissements PHP.

Ces avertissements incluent les chemins complets du serveur et les versions des plugins, exactement ce qu'un attaquant utilise pour choisir quel exploit essayer. Et aujourd'hui il n'y a rien de sensible ; demain, avec une nouvelle erreur, il peut y en avoir.

Dois-je désactiver complètement les journaux ?

Non. Il faut qu'ils ne soient pas publics. Journalise ce que tu veux dans un dossier que le serveur web ne sert pas, ou dans un service externe.

Est-ce que ça me concerne sur Vercel ou Netlify ?

Presque jamais : là, les journaux ne sont pas écrits dans des fichiers publics, ils se consultent dans le tableau de bord. Le constat apparaît surtout sur les serveurs auto-hébergés, WordPress et l'hébergement mutualisé.