Google dorking : la technique avancée pour dénicher des infos cachées

Google Dorking : le moteur de recherche qui en sait trop sur vous

Vous tapez une requête dans Google, vous obtenez des résultats. Banale, l'affaire. Mais si je vous disais qu'avec trois opérateurs malins, vous pouvez tomber sur des fichiers de configuration de serveurs, des bases de données clients, ou même des mots de passe en clair ? Ce n'est pas de la magie. C'est le Google Dorking.

Et franchement, ça fait froid dans le dos.

Qu'est-ce que le Google Dorking ? (et non, ça n'a rien à voir avec des poules)

Allez, commençons par tordre le cou à une confusion courante. Si vous tapez "dorking" dans le dictionnaire Larousse, vous tombez sur ceci : "Se dit d'une race de poules d'origine anglaise élevée pour sa chair." Pas de bol, on n'est pas là pour parler de volailles.

Le "Google Dork" vient du terme "dork" employé par les communautés de hackers pour désigner une technique ou un script rudimentaire — un truc qui marche parce que la cible est mal configurée. Le Google Dorking, c'est l'art d'exploiter les fonctionnalités du moteur de recherche pour faire remonter à la surface des informations qui n'auraient jamais dû être indexées.

En clair : Google est un aspirateur géant. Il indexe tout ce qu'il trouve. Et parfois, il tombe sur des fichiers que le propriétaire du site croyait bien cachés. Un fichier CSV contenant des adresses email. Un backup SQL. Un fichier de logs avec des tokens d'accès. Tout ça est potentiellement accessible via une simple recherche.

Comment ça marche techniquement ?

Le mécanisme, il est simple. Google crawle le web via ses robots (les fameux Googlebots). Ces bots suivent les liens, explorent les pages, et indexent leur contenu. Le problème ? Ils ne savent pas faire la différence entre une page publique destinée aux visiteurs et un fichier de configuration que le webmaster a laissé traîner dans un dossier mal protégé.

Là où ça devient intéressant (et flippant), c'est que Google expose ces fichiers dans ses résultats de recherche. Pas besoin d'être un génie de l'informatique pour les trouver. Un enfant de 12 ans avec une connexion internet peut, en théorie, taper la bonne requête et tomber sur des données sensibles.

Quels sont les opérateurs Google Dorks ?

Vous les utilisez peut-être déjà sans le savoir pour affiner vos recherches quotidiennes. Mais poussés dans leurs retranchements, ils deviennent de redoutables outils.

Voici les principaux opérateurs que j'utilise personnellement depuis des années :

• filetype: – Limite les résultats à un type de fichier précis. filetype:pdf, filetype:xls, filetype:sql. C'est mon préféré.
• intitle: – Cherche un mot dans le titre de la page. intitle:"index of" est un classique pour trouver des répertoires ouverts.
• inurl: – Cherche un terme dans l'URL. inurl:admin peut révéler des panneaux d'administration sans mot de passe.
• site: – Limite à un domaine spécifique. Indispensable pour auditer son propre site.
• ext: – Variante de filetype:, tout aussi efficace.
• intext: ou allintext: – Cherche dans le corps de la page.

L'opérateur le plus sous-estimé selon moi ? cache:. Il affiche la version en cache d'une page. Pratique pour voir ce que Google a indexé d'une URL que vous pensiez avoir supprimée.

Google Dorking : exemples concrets qui font réfléchir

Bon, passons aux choses sérieuses. Je ne vais pas vous donner la recette pour pirater la NASA, mais je peux vous montrer des requêtes qui révèlent à quel point le web est mal configuré.

Exemple n°1 : les répertoires ouverts

intitle:"index of" "parent directory" – Cette requête liste tous les répertoires de sites qui n'ont pas de page d'accueil et dont le listing est activé. Résultat ? Vous tombez sur des arborescences complètes de fichiers. J'ai déjà trouvé, sur un site de e-commerce, un dossier /backup/ contenant une base de données de 2019. Pas de mot de passe. Pas de restriction. Juste un fichier SQL qui traînait.

Exemple n°2 : les fichiers de configuration exposés

filetype:env DB_PASSWORD – Les fichiers .env sont utilisés pour stocker les variables d'environnement d'une application, dont les mots de passe de base de données. Il y a quelques années, je suis tombé par hasard sur le fichier .env d'une startup française. Le mot de passe de leur base PostgreSQL était en clair. J'ai prévenu le CTO. Il ne m'a pas cru. J'ai dû lui envoyer une capture d'écran.

Exemple n°3 : les données personnelles qui fuient

filetype:xls intext:"email" intext:"mot de passe" – Ça semble trop gros pour être vrai. Et pourtant. J'ai personnellement trouvé, en une dizaine de minutes, un fichier Excel listant 300 comptes utilisateurs avec emails et mots de passe en clair, pour une formation en ligne. Le fichier datait de 2018 et traînait toujours sur un sous-domaine oublié du prestataire.

Google Dorking : entre outil légitime et terrain glissant

C'est là que ça se corse. Le Google Dorking n'est pas illégal en soi. Utiliser Google, ce n'est pas un délit. Le problème, c'est ce que vous faites des informations que vous trouvez.

L'usage éthique

Les experts en cybersécurité utilisent ces techniques pour auditer leurs propres systèmes ou ceux de clients avec autorisation. On appelle ça du pentest ou de l'audit de surface d'exposition. L'idée, c'est de trouver les failles avant les vrais malfaisants.

J'ai un ami qui bosse dans un grand cabinet de conseil en sécurité. Il m'a raconté que leur première étape, sur 80% de leurs missions, c'est une campagne de Google Dorking. Ils trouvent des choses en 5 minutes qui auraient dû rester confidentielles. Et ça leur permet de dire au client : "Voilà ce qu'un hacker verrait. Bouchez ces trous."

Les risques juridiques

Si vous tombez sur un fichier contenant des données personnelles et que vous les exploitez sans autorisation, vous enfreignez le RGPD. Article 32 : obligation de confidentialité. Si vous les utilisez pour pénétrer un système, vous basculez dans le pénal. En France, l'accès frauduleux à un système de traitement automatisé de données (STAD) est passible de deux ans d'emprisonnement et de 60 000 euros d'amende.

La frontière est fine. Et franchement, mieux vaut ne pas la tester.

Comment se protéger contre le Google Dorking ?

Si vous gérez un site web, vous n'êtes pas impuissant. Voici les mesures que j'applique systématiquement.

Auditer régulièrement votre exposition

Faites la recherche en direct. Tapez site:votresite.com et regardez ce qui s'affiche. Faites-le avec des opérateurs : site:votresite.com filetype:sql, site:votresite.com filetype:env, site:votresite.com intitle:"index of". Si vous trouvez quelque chose d'anormal, supprimez-le de votre serveur et demandez la suppression du cache Google via la Search Console.

Le fichier robots.txt bien configuré

Le fichier robots.txt à la racine de votre site indique aux robots ce qu'ils peuvent ou ne peuvent pas indexer. Mais attention : c'est un contrat d'honneur. Un robot malveillant ne le respectera pas. En revanche, Google le respecte. Exemple de blocage :

User-agent: *
Disallow: /backup/
Disallow: /config/
Disallow: /logs/

Protéger les fichiers sensibles

Ne laissez jamais un fichier sensible (base de données, mot de passe, clé API) dans un dossier accessible via le web. Placez-le en dehors du répertoire racine de votre serveur web. Si vous devez absolument le laissez accessible, protégez-le par un fichier .htaccess ou une authentification HTTP.

Google Dorking gratuit : les outils qui existent

Il existe des bases de données de dorks prêtes à l'emploi, comme le Google Hacking Database (GHDB). C'est une collection maintenue par la communauté, classée par catégorie (fichiers contenant des mots de passe, pages de connexion, vulnérabilités connues, etc.). Attention : c'est une mine d'or pour un chercheur en sécurité, mais aussi pour un attaquant.

Mon conseil : utilisez ces listes uniquement pour tester votre propre infrastructure. Ne les appliquez jamais sur un site dont vous n'êtes pas le propriétaire ou sans accord écrit. Je le dis parce que je vois encore trop de stagiaires en cybersécurité qui veulent "s'entraîner" sur des sites réels. Mauvaise idée.

Une liste des commandes essentielles

Opérateur	Syntaxe	Usage
filetype	`filetype:pdf mot`	Fichiers PDF
intitle	`intitle:"index of"`	Répertoires ouverts
inurl	`inurl:admin`	Pages d'admin
site	`site:exemple.com`	Restreindre au domaine
intext	`intext:mot_de_passe`	Texte dans la page
cache	`cache:url`	Version en cache
link	`link:url`	Pages pointant vers l'URL
related	`related:url`	Pages similaires
allinurl	`allinurl:admin login`	Plusieurs termes dans l'URL

J'ai volontairement omis des combinaisons trop dangereuses. Si vous cherchez "Google Dorking liste complète" sur les forums, vous trouverez. Mais sachez ce que vous faites.

Google Dorks et WhatsApp : un cas d'école

Vous avez peut-être vu passer des articles parlant de "Google Dorks WhatsApp". Le principe est simple : certains groupes ou numéros de téléphone associés à des comptes WhatsApp peuvent être exposés via des pages mal configurées. Par exemple, si un site liste des contacts WhatsApp publics (groupes d'entreprise, support client), et que cette page est indexée, on peut retrouver ces données avec une recherche.

C'est un bon exemple de la porosité entre vie privée et indexation. Ce qui est sur le web finit tôt ou tard dans Google. Et ce qui est dans Google peut être trouvé par n'importe qui.

Pourquoi Google indexe-t-il ces données sensibles ?

La réponse est simple : parce qu'il le peut. Google n'a pas de filtre magique pour distinguer une page web normale d'un fichier de configuration. Il se contente de suivre les liens et d'indexer ce qu'il trouve.

Si un fichier est accessible en HTTP (sans authentification), Google le considère comme public. C'est la responsabilité du propriétaire du site de le protéger. Google propose des outils (comme la Search Console) pour demander la suppression d'URLs, mais c'est au site de faire le ménage en amont.

Et maintenant ?

Le Google Dorking n'est ni bon ni mauvais en soi. C'est un outil. Comme un couteau. On peut couper du pain ou blesser quelqu'un. La différence, c'est ce qu'il y a entre vos mains et vos intentions.

Si vous êtes développeur, webmaster ou responsable sécurité, consacrez une après-midi par mois à auditer votre propre exposition. Vous serez surpris (et pas toujours en bien) de ce que Google sait de vous.

Et si vous êtes simplement curieux, souvenez-vous de la règle d'or : regarder, ce n'est pas interdit. Toucher, c'est une autre histoire.