Scanner de fichiers sensibles

Comment fonctionne cette vérification

Scanaris demande une liste de chemins où traînent souvent des fichiers qui ne devraient jamais se trouver sur un serveur public : .env, .env.local, .env.production, .git/config, .git/HEAD, wp-config.php, config.json, docker-compose.yml, backup.sql, phpinfo.php, .npmrc, Dockerfile, .gitlab-ci.yml, .aws/credentials, .ssh/id_rsa, web.config, adminer.php et .DS_Store. Un 200 ne suffit pas à signaler quoi que ce soit : beaucoup d'applications monopage répondent 200 avec leur HTML sur n'importe quel chemin. C'est pourquoi le scanner vérifie que le contenu a l'air réel, par exemple qu'un .env contient des lignes CLE=valeur et n'est pas du HTML, ou que .git/HEAD commence par ref:. La sévérité dépend du fichier : critique pour .env, les sauvegardes de base de données et les clés privées ; élevée pour .git et les configurations serveur ; faible pour .DS_Store ou un Dockerfile.

Ce qu'un attaquant fait avec ça

La même chose que le scanner, mais contre tous les domaines existants. Un .env accessible livre d'un coup les identifiants de la base, les clés de paiement et les jetons d'e-mail. Un répertoire .git exposé permet de télécharger le dépôt complet avec un outil en ligne de commande, avec tout l'historique, y compris les clés supprimées dans un commit ultérieur. Un backup.sql, c'est ta base entière, utilisateurs et mots de passe hachés compris. C'est l'une des failles les plus simples à exploiter et les plus graves.

Pourquoi ça arrive

Deux causes. La première, c'est de déployer le dossier du projet entier au lieu du dossier de sortie du build : tout ce qui est dans le dépôt devient servable. La seconde, c'est un serveur web (nginx, Apache, IIS) qui sert un dossier où l'on développe aussi ou où l'on fait des sauvegardes. Les plateformes comme Vercel ou Netlify ne publient que le dossier de sortie, c'est pourquoi là-bas cette faille se réduit généralement à des fichiers copiés par erreur dans public/.

Comment corriger

• Retire le fichier et fais tourner tout ce qu'il contenait. Si un .env a été accessible, chaque clé qu'il contient est compromise même si personne ne t'a prévenu.
• Déploie seulement la sortie du build (dist/, .output/, .next/), jamais la racine du projet. En Express, express.static doit pointer vers ce dossier.
• Bloque les chemins côté serveur comme seconde barrière. En nginx : location ~ /\.(?!well-known) { deny all; } bloque tout ce qui commence par un point sauf .well-known ; ajoute des règles pour *.sql, *.yml et *.log. En Apache, l'équivalent avec FilesMatch et Require all denied.
• Vérifie le dossier public/ de ton projet : il ne doit rien contenir d'autre que des images, des polices ou des fichiers destinés au téléchargement.
• Regarde les journaux d'accès à la recherche de requêtes vers /.env ou /.git avec une réponse 200, pour savoir si quelqu'un est passé avant toi.

Vérifie que c'est corrigé

for p in .env .env.local .git/config .git/HEAD config.json backup.sql docker-compose.yml .npmrc; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tondomaine.com/$p"
done

Attendu : 404 ou 403 partout. Un 200 sur une SPA peut être le HTML habituel : ouvre-le et confirme que ce n'est pas le vrai fichier.

Questions fréquentes

Mon site renvoie 200 sur tous les chemins. Va-t-il signaler des faux positifs ?

Non. Le scanner valide le contenu avant d'ouvrir un constat ; un HTML générique ne compte pas comme un .env.

Pourquoi .DS_Store est-il un constat s'il ne contient pas de secrets ?

Parce qu'il liste les noms des fichiers du dossier, y compris ceux que tu ne lies depuis aucune page. C'est une carte gratuite pour qui cherche des sauvegardes ou des fichiers oubliés. Sévérité faible, mais à retirer.

Et les chemins .well-known ?

Ceux-là doivent être accessibles : c'est là que vivent security.txt, les vérifications de domaine et les certificats. La règle nginx de l'exemple les exclut du blocage.