Google Dorks & GIT

Dorks Google autour de Git : repérer les dépôts exposés et protéger son code

Les requêtes ci-dessous cherchent des indices de dépôts Git ou de fichiers associés accessibles depuis le Web. Elles peuvent aider une équipe à vérifier ses propres domaines et à repérer une erreur de configuration. Un résultat ne prouve toutefois pas, à lui seul, qu’un dépôt est exploitable : il faut le vérifier dans un cadre autorisé.

Pourquoi les dossiers Git exposés posent problème

Un dépôt Git peut contenir l’historique du code, des noms de branches et des fichiers supprimés depuis. S’il est accessible publiquement par erreur, il peut révéler des informations internes ou des secrets qui auraient dû rester privés.

La présence de fichiers comme .gitconfig ou ORIG_HEAD peut indiquer qu’une partie du dépôt est indexée ou accessible. Les fichiers .git-credentials, eux, méritent une attention particulière : selon leur contenu et leur exposition, ils peuvent divulguer des identifiants. Même un dépôt sans mot de passe peut révéler l’architecture d’une application ou des détails utiles à un attaquant.

Que ciblent ces requêtes ?

Requête	Indice recherché
inurl:.git-credentials	Une URL contenant un nom de fichier d’identifiants Git.
inurl:.gitconfig	Une page ou un fichier lié à la configuration Git.
intext:"index of /.git" "parent directory"	Une page d’index de répertoire pouvant exposer un dossier .git.
filetype:git -github.com inurl:"/.git"	Des résultats associés à .git, en excluant les pages GitHub.
(intext:"index of /.git") ("parent directory")	Une variante de recherche de listes de fichiers .git.
inurl:ORIG_HEAD	Un fichier interne de référence Git potentiellement exposé.
intitle:"index of" ".gitignore"	Des index de répertoire mentionnant .gitignore.
".git" intitle:"Index of"	Des pages d’index contenant une référence à .git.
"Parent Directory" "Last modified" git	Des listings de fichiers dont le titre ou le contenu évoque Git.
inurl:git	Une recherche très large de pages dont l’URL contient « git ».

Ces requêtes peuvent produire des faux positifs, des résultats incomplets ou des pages obsolètes. Les moteurs de recherche ne montrent pas nécessairement tout ce qui est accessible, et un résultat absent ne garantit pas qu’aucun fichier n’est exposé.

Comment vérifier un résultat sans prendre de risque

Si vous administrez le domaine concerné, vérifiez le résultat dans votre propre environnement et avec les autorisations nécessaires. Évitez de télécharger ou de parcourir des données qui ne vous appartiennent pas. Si le domaine appartient à un tiers, signalez l’exposition au propriétaire ou à son équipe de sécurité via un canal officiel, sans tenter d’accéder davantage au contenu.

Pour votre propre site, contrôlez les règles de publication et les réponses du serveur : un dépôt ne doit pas être servi depuis la racine Web. Ne publiez pas le répertoire .git avec les fichiers du site, et ne comptez pas uniquement sur une règle d’exclusion de l’indexation pour protéger des fichiers accessibles.

Checklist de protection

• Exclure le répertoire .git du déploiement et de la racine publique.
• Refuser côté serveur les requêtes vers .git et les fichiers Git associés.
• Vérifier les artefacts construits et les archives avant publication.
• Stocker les secrets dans un gestionnaire dédié ou dans des variables d’environnement, jamais dans le dépôt.
• Si un secret a été exposé, le révoquer et le remplacer immédiatement. Le supprimer du dernier commit ne suffit pas toujours : il peut rester dans l’historique.
• Examiner les journaux d’accès pour repérer d’éventuelles consultations non autorisées.
• Ajouter un contrôle automatisé dans le processus de déploiement pour détecter les fichiers sensibles.

À retenir

Ces dorks servent à repérer des indices d’exposition de Git, pas à établir à eux seuls qu’une faille est présente. Pour une organisation, le meilleur usage consiste à surveiller ses propres domaines, corriger les configurations de publication et traiter rapidement tout secret potentiellement divulgué.