Un fichier comme .git, .env ou docker-compose.yml qui reste dans le dossier public d'un site est téléchargeable par n'importe qui, robots compris. Il peut livrer le code source complet, les mots de passe de la base de données ou les clés d'API. Pour le savoir, demandez directement ces adresses à votre site et vérifiez le contenu réel de la réponse, pas seulement son code HTTP. Pour corriger, retirez ces fichiers du déploiement, bloquez-les au niveau du serveur web, puis changez tous les secrets qui ont pu être lus.
Ce que nous trouvons sur des sites bien réels
En analysant les sites de nos utilisateurs, nous avons trouvé un dossier .git entièrement accessible sur deux sites, et des fichiers docker-compose.yml et package.json lisibles sur plusieurs autres. Aucun de ces propriétaires ne le savait. Ce ne sont pas des sites abandonnés : ce sont des sites d'entreprise maintenus et mis à jour.
Ces fichiers ne s'affichent nulle part sur le site : aucun lien n'y mène, aucun visiteur ne tombe dessus par hasard. C'est pour cela qu'ils restent en place des années. Ceux qui les trouvent sont des robots qui testent les mêmes adresses sur tous les sites qu'ils croisent.
La cause est presque toujours la même : le site est déployé en copiant tout le dossier du projet sur le serveur, y compris les fichiers de travail du développeur. Le serveur web sert ensuite tout ce qui se trouve dans le dossier public.
Ce que chaque fichier révèle
| Fichier | Ce qu'il contient | Risque |
|---|
.git/ | L'historique complet du projet | Reconstitution du code source et de tout l'historique, y compris des identifiants supprimés depuis |
.env | La configuration de l'application | Mots de passe de base de données, clés d'API, identifiants SMTP, clé de chiffrement de l'application |
docker-compose.yml | La description des services | Architecture, noms des services, ports internes, parfois mots de passe en clair |
package.json, composer.lock | La liste des dépendances | Versions exactes des bibliothèques, donc liste des vulnérabilités connues à essayer |
*.sql, *.zip, *.tar.gz | Des sauvegardes | Base de données complète (clients, commandes, mots de passe hachés) ou site entier |
phpinfo.php | La configuration PHP | Versions, chemins du serveur, variables d'environnement |
wp-config.php.bak, wp-config.php~ | Une copie de la configuration WordPress | Le serveur ne l'exécute pas : il l'affiche en texte, avec les identifiants de la base |
Le dossier .git est le plus sous-estimé. Même si le serveur interdit de lister son contenu, des outils publics savent le reconstituer fichier par fichier à partir de quelques adresses connues, comme .git/HEAD et .git/config.
Demandez les fichiers un par un et regardez la réponse :
curl -s -o /dev/null -w "%{http_code}\n" https://www.exemple.fr/.git/HEAD
curl -s https://www.exemple.fr/.git/HEAD
curl -s https://www.exemple.fr/.env | head -5
curl -s https://www.exemple.fr/docker-compose.yml | head -5
Un fichier .git/HEAD réellement exposé contient une ligne du type ref: refs/heads/main. Un fichier .env exposé contient des lignes NOM=valeur, comme DB_PASSWORD=. Si vous voyez ce contenu, le fichier est public.
Pourquoi le code HTTP ne suffit pas
Beaucoup de scanners se contentent du code de réponse, et se trompent dans les deux sens :
- Faux positifs : de nombreux sites renvoient leur page « introuvable » avec un code
200 au lieu de 404. Un scanner naïf annonce alors que .env existe, alors qu'il ne reçoit que la page d'erreur habillée.
- Faux négatifs : un
403 ne prouve pas que le fichier est absent ni protégé partout. Le dossier .git/ peut renvoyer 403 tandis que .git/config ou .git/HEAD restent lisibles.
La seule preuve fiable est la signature du contenu : la ligne ref: d'un HEAD, la section [core] d'un .git/config, les clés services: d'un docker-compose.yml. C'est ainsi que travaille l'outil Fichiers sensibles : il ne signale un fichier que si son contenu correspond à ce qu'il est censé être.
1. Ne plus déployer ces fichiers
La vraie correction est en amont. Déployez à partir d'une archive ou d'un build qui ne contient que le nécessaire, ou placez le dossier public de l'application à part (public/ pour Laravel ou Symfony) et faites-le pointer comme racine du site. Le fichier .env et le dossier .git se trouvent alors hors de portée du serveur web.
2. Bloquer les accès au niveau du serveur
En attendant, ou en complément, interdisez ces fichiers dans la configuration du serveur.
Avec Apache, dans le .htaccess à la racine du site :
# Fichiers sensibles : réponse 403
<FilesMatch "^(\.env.*|docker-compose\.ya?ml|composer\.(json|lock)|package(-lock)?\.json|phpinfo\.php|.*\.(sql|bak|old|zip|tar\.gz))$">
Require all denied
</FilesMatch>
# Dossiers cachés (.git, .svn…) : réponse 404
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Avec Nginx, dans le bloc server :
location ~ /\.(git|svn|hg|env) {
deny all;
return 404;
}
location ~* (docker-compose\.ya?ml|composer\.(json|lock)|package(-lock)?\.json|phpinfo\.php|\.(sql|bak|old))$ {
deny all;
return 404;
}
Rechargez ensuite le serveur (sudo nginx -t && sudo systemctl reload nginx) et refaites les tests curl. Les fichiers doivent maintenant répondre en 403 ou 404, sans contenu.
3. Changer tous les secrets exposés
Bloquer l'accès ne rend pas confidentiel ce qui a déjà été lu. Partez du principe que tout secret présent dans un fichier exposé est connu :
- changez le mot de passe de la base de données et les identifiants SMTP ;
- révoquez et régénérez les clés d'API (paiement, emails, stockage) ;
- régénérez la clé de chiffrement de l'application si elle était dans
.env ;
- pour un dépôt
.git exposé, vérifiez aussi l'historique : un mot de passe supprimé dans un commit récent reste lisible dans les anciens.
Bonus : les portes d'administration trop faciles à trouver
Deux autres points reviennent souvent lors de nos analyses :
- PrestaShop : le dossier d'administration est renommé à l'installation, mais certains sites utilisent un nom prévisible (
/admin, /administration, /parametrage). Une page de connexion trouvée en quelques essais devient une cible d'attaques par mot de passe. Choisissez un nom aléatoire et activez la double authentification.
- WordPress : la page
/wp-login.php est connue de tous les robots. Le risque reste faible avec des mots de passe solides, mais une extension qui change cette adresse et une double authentification réduisent beaucoup le bruit des tentatives.
Pour un contrôle complet du domaine, fichiers exposés compris, lancez l'audit gratuit. Les en-têtes de sécurité, autre réglage serveur souvent oublié, sont expliqués dans HTTP Security Headers : HSTS, CSP, X-Frame-Options.
Questions fréquentes
Mon fichier .env renvoie 403, suis-je protégé ?
Pour ce fichier précis, oui, tant que le contenu n'apparaît pas. Vérifiez quand même les variantes (.env.local, .env.production, .env.bak) et les autres fichiers de la liste. Une règle de blocage trop précise laisse souvent passer une copie.
Un dossier .git exposé est-il grave si le dépôt est public sur GitHub ?
Moins, car le code est déjà connu. Mais le dossier du serveur contient souvent des branches, des fichiers ou des commits qui ne sont pas sur GitHub, et sa configuration peut contenir une adresse de dépôt avec identifiants. Bloquez-le dans tous les cas.
Comment savoir si quelqu'un a déjà téléchargé ces fichiers ?
Cherchez les requêtes vers /.git/, /.env ou les sauvegardes dans les journaux d'accès du serveur, avec une réponse 200. Si les journaux ne remontent pas assez loin, considérez que le fichier a été lu et changez les secrets.
Les robots cherchent-ils vraiment ces fichiers ?
Oui. Les journaux de n'importe quel site public montrent des requêtes automatiques vers /.env, /.git/config ou /wp-config.php.bak, souvent plusieurs fois par jour. Ce ne sont pas des attaques ciblées : ces robots testent tous les sites qu'ils trouvent.