Répertoire .git exposé : la fuite de code source cachée à la vue de tous
Lorsqu'un serveur web sert le répertoire .git avec les fichiers de votre application, un attaquant peut télécharger assez d'objets pour reconstruire votre code source complet — y compris chaque secret jamais committé, même s'il a été supprimé dans un commit ultérieur. AppSafe signale ce problème comme critique.
Ce que c’est
Git stocke l'intégralité du dépôt — chaque fichier, chaque commit, chaque pointe de branche — dans un répertoire caché .git à la racine du projet. Si ce répertoire se retrouve dans votre racine web et que votre serveur n'en bloque pas l'accès, les fichiers /.git/config, /.git/HEAD et le magasin d'objets sous /.git/objects/ sont téléchargeables publiquement.
Reconstruire le code source complet à partir d'un répertoire .git exposé est simple. Des outils comme git-dumper récupèrent l'index puis chaque objet référencé, produisant un checkout parfaitement fonctionnel. Les attaquants n'ont pas besoin d'un accès shell — un navigateur suffit.
Pourquoi ça compte
Votre code source contient très probablement des informations qui augmentent le risque : des clés API codées en dur (souvent dans d'anciens commits), des schémas de base de données, des chemins d'endpoints internes, la logique métier et les flux d'authentification. Même si aucun secret n'est actuellement committé, l'historique regorge de matériel exploitable par un attaquant.
L'historique Git est permanent par conception. Un secret committé il y a des années puis supprimé vit toujours dans le magasin d'objets et est téléchargé avec tout le reste. Le faire tourner (rotation) est le seul moyen de le neutraliser.
Comment corriger
Refusez toutes les requêtes dont le chemin commence par /.git/. Renvoyez 404 plutôt que 403 pour ne pas confirmer l'existence du répertoire.
location ~ /\.git {
deny all;
return 404;
}La solution la plus fiable consiste à ne jamais déployer le répertoire .git dans la racine des documents. Structurez votre build pour que la sortie compilée aille dans un répertoire public/ séparé, et ne déployez que celui-ci, pas la racine du projet.
Après avoir déployé le correctif, ouvrez https://yourdomain.com/.git/config dans un navigateur. La réponse doit être 404, et non le contenu de votre configuration Git. AppSafe revérifie ce point à chaque scan.
Si le répertoire était accessible, considérez comme compromis chaque clé API, mot de passe et token apparu dans un commit, quel qu'il soit. Faites-les tourner — supprimer le commit ne suffit pas, car l'objet existe toujours dans les fichiers pack qu'un attaquant a peut-être déjà téléchargés.
FAQ
Je déploie sur une plateforme managée (Vercel, Netlify, Fly.io) — suis-je exposé ?
Les plateformes managées qui buildent à partir du code source ne déploient généralement que la sortie du build, donc le répertoire .git n'est pas servi. Le risque est plus élevé avec les déploiements sur VPS, les conteneurs Docker construits depuis la racine du projet ou les exports de sites statiques qui copient tout l'arbre de travail.
Que vérifie concrètement AppSafe ?
AppSafe interroge /.git/config et /.git/HEAD et vérifie si le corps de la réponse ressemble à un vrai fichier Git (correspondant aux motifs [core] ou ref:). Une page générique en 200 qui ne contient pas de contenu Git n'est pas signalée.
Puis-je simplement supprimer le répertoire .git sur le serveur ?
Oui, si vous n'avez besoin que des fichiers déployés pour faire tourner l'application. Mais assurez-vous que votre processus de déploiement ne le recopie pas au prochain push. Le bloquer aussi au niveau du serveur web offre une double protection lorsque les scripts de déploiement ne sont pas cohérents.
Votre app est-elle concernée ?
AppSafe détecte ce problème et des dizaines d’autres en un seul scan gratuit.
Scanner mon app gratuitementSur le blog
De faux robots d’IA traquent vos fichiers .env. Voici comment vérifier les vôtres
Des scanners d’identifiants empruntent le nom de robots d’IA pour passer les listes d’autorisation, et ils réclament un fichier bien précis : votre .env. Comment vérifier s’il est accessible, et comment le verrouiller.
La fuite chez Railway : comment renouveler les secrets de votre app sans interruption
Railway a demandé à tous ses utilisateurs de renouveler leurs variables d’environnement après que des attaquants ont ciblé des clés API d’IA et de plateformes. Comment évaluer votre exposition, tout renouveler sans mettre votre app hors service, et rendre la prochaine fuite moins douloureuse.
PHP2Shell est exploité : comment vérifier si votre app est exposée
Deux bugs critiques dans PHP lui-même sont passés de « correctif publié » à « exploité dans la nature » en quelques jours. Comment savoir si ce que vous hébergez utilise une version affectée, et quoi faire dès aujourd’hui.
Guides liés
Fichiers .env exposés : comment les attaquants trouvent vos secrets
Un seul .env accessible peut livrer toute votre stack.
Les source maps en production divulguent votre code source
Les fichiers .map livrés donnent accès à votre code source original.
Index de répertoires ouverts : quand votre serveur de fichiers liste tout
Un serveur de fichiers qui liste son contenu offre aux attaquants un inventaire gratuit.
Sauvegardes de base de données exposées : que se passe-t-il quand /backup.sql est accessible
Un dump .sql accessible, c'est la remise complète de toute votre base de données.