Google dorking : 7 requêtes qui révèlent des secrets cachés

Un client m'appelle un mardi matin, affolé. Il a tapé son nom de domaine dans Google, comme ça, par curiosité. Résultat en deuxième page : un fichier .env contenant ses identifiants de base de données, en clair, indexé depuis des mois. Personne ne l'avait trouvé avant lui. Ou personne ne lui avait dit.

C'est ça, le google dorking. Pas une technique de hacker dans un film. Juste Google qui fait son travail — indexer tout ce qu'on lui laisse voir — et quelqu'un qui sait poser la bonne question. Dans mon cas, le fichier était là depuis dix-huit mois. Le site n'avait jamais bougé. Le client, si.

Le google dorking, c'est quoi au juste (et pourquoi ça vous concerne)

Le google hacking, également appelé google dorking, est une technique de reconnaissance qui exploite les opérateurs de recherche avancés de Google pour identifier des vulnérabilités exposées publiquement sur un site : identifiants non chiffrés, répertoires ouverts, logiciels obsolètes. Voilà pour la définition propre.

Maintenant, la version terrain. Google est un robot qui lit tout ce qu'il peut atteindre. Si vous laissez traîner un dossier /backup sans protection, il finira par le trouver et par le publier. Le dorking, c'est simplement l'art de demander à Google ce qu'il a déjà vu.

Non, ce n'est pas du piratage

On me pose souvent la question avec un air suspicieux. Est-ce que faire ça, c'est illégal ? Réponse courte : non, tant que vous restez dans la consultation de résultats publics. Un moteur de recherche qui affiche une page accessible sans authentification, c'est un moteur qui fait son boulot.

Ce qui devient problématique, c'est d'aller plus loin : utiliser les informations trouvées pour accéder à un système, extraire des données, contourner une protection. Là, on change de registre juridique. Le dorking n'est qu'une loupe. Ce que vous faites de ce que vous voyez, ça vous regarde.

D'où le positionnement défensif : la plupart des professionnels de la sécurité utilisent ces requêtes sur leur propre domaine avant que quelqu'un d'autre ne le fasse.

Les opérateurs qui font tout le travail

Google propose une petite dizaine d'opérateurs qui transforment une recherche banale en requête chirurgicale. On n'a pas besoin de tous les connaître. Quatre ou cinq suffisent à couvrir 90 % des cas.

Les cinq opérateurs à maîtriser en premier

Opérateur	Ce qu'il fait	Exemple concret
site:	Limite la recherche à un domaine	site:exemple.com filetype:pdf
filetype: / ext:	Cherche un type de fichier précis	site:exemple.com ext:env
intitle:	Le terme doit apparaître dans le titre de la page	intitle:"index of"
inurl:	Le terme doit apparaître dans l'URL	inurl:admin
after:	Filtre par date de publication	site:exemple.com after:2025-01-01

Les combiner change tout. site:exemple.com ext:env ne vous dit pas juste « il y a des fichiers .env ». Il vous dit « il y a des fichiers .env accessibles depuis votre site, et Google les connaît ». C'est une information très différente.

Les trois requêtes à taper sur votre propre site dès aujourd'hui

Voici les dorks que je lance systématiquement lors d'un audit rapide. Ils tiennent en une ligne chacun.

• site:votredomaine.com intitle:"index of" — révèle les répertoires laissés en listing ouvert. Si vous voyez des noms de dossiers, vous avez un problème.
• site:votredomaine.com ext:env OR ext:log OR ext:sql — fichiers de configuration, journaux, sauvegardes de base. Le genre de chose qui ne devrait jamais être indexé.
• site:votredomaine.com inurl:admin — panneaux d'administration exposés. Pas une faille en soi, mais une cible signalée.

Ce que chaque résultat vous apprend : Google a ramené cette page à la surface, donc elle est atteignable par un inconnu. Même sans mot de passe, c'est déjà une info. Avec un mot de passe faible en plus, ça devient une porte.

Protéger son site : les trois verrous qui comptent

Les dorks, on ne les « bloque » pas. On retire de la surface ce qu'ils pourraient trouver. Trois mécanismes font 95 % du job.

robots.txt et balises d'indexation

Le fichier robots.txt à la racine du site indique aux robots ce qu'ils ne doivent pas parcourir. Les balises <meta name="robots" content="noindex"> sur une page, ou l'en-tête HTTP X-Robots-Tag, donnent la même consigne au niveau de la page ou de la réponse serveur. Attention : robots.txt empêche le parcours, pas l'indexation si une page est déjà connue ou liée ailleurs. Pour retirer un contenu, il faut le noindex, ou une demande de suppression dans la console de recherche.

Chiffrer, puis scanner

Une donnée chiffrée correctement reste chiffrée même si le fichier fuite. C'est le second verrou, et probablement le plus rentable. Le troisième, c'est le scan régulier : on lance les trois requêtes d'audit une fois par trimestre, on corrige ce qui apparaît, on recommence.

Le client dont je parlais en ouverture ? Le fichier .env n'avait pas de permission d'accès particulière. Un site:son-domaine.com ext:env l'aurait révélé. Le correctif a pris quinze minutes. Le temps qu'il aurait passé à gérer une fuite, lui, se compte en semaines.

Comment savoir si Google est piraté ?

La question se pose souvent formulée ainsi, et il faut la décoder : on ne demande pas si « Google » est piraté — Google n'est pas piraté dans l'immense majorité des cas. On demande comment savoir si son propre site apparaît compromis dans les résultats. Trois signaux doivent vous alerter.

• Des URLs étranges apparaissent avec site:votre-domaine.com que vous n'avez jamais créées. Pages de phishing, redirections, contenus injectés.
• Le titre affiché dans les résultats ne correspond plus à celui de votre page. Un attaquant peut modifier ce que Google indexe.
• Vos pages légitimes renvoient vers des domaines inconnus, ou votre site se retrouve blacklisté par les navigateurs.

Le premier réflexe : taper site:votre-domaine.com et parcourir les résultats. Si le volume dépasse largement le nombre de vos pages, quelque chose a été ajouté sans vous. Ensuite, la console de recherche liste les pages indexées et permet de demander une suppression. Ce n'est pas une procédure de sécurité, mais c'est un excellent détecteur d'anomalies.

Quelles sont les choses à ne jamais chercher sur Google ?

Il y a des requêtes qu'on ne tape pas, même « pour voir ». Pas par superstition : pour des raisons très pratiques.

D'abord, les dorks ciblant des identifiants, des mots de passe ou des bases de données exposées. Non pas parce que Google le refuse — il les trouvera peut-être — mais parce que consulter puis utiliser ces informations vous met hors la loi, et parce que les fichiers eux-mêmes peuvent contenir des malwares ou être des leurres. Ensuite, les requêtes qui visent les infrastructures d'autrui sans autorisation écrite. Enfin, tout ce qui relève des données personnelles de tiers : un dork qui remonte des carnets d'adresses, des dossiers clients, des pièces d'identité scannées.

La règle que j'applique : si vous ne possédez pas le domaine, ne lancez pas le dork. Sur le vôtre, en revanche, tapez tout ce qui vous passe par la tête. C'est la seule façon de savoir ce que Google sait de vous.

Ce que le dorking ne résout pas

Il faut le dire clairement : le google dorking est une technique d'observation, pas de protection. Il révèle ce qui est visible. Il ne répare rien, ne chiffre rien, ne ferme aucun répertoire. J'ai vu des équipes découvrir un répertoire ouvert grâce à un dork, puis repousser la correction de trois semaines. Résultat : cinq semaines d'exposition supplémentaires, dont trois connues.

Et puis il y a la limite du temps. Google désindexe lentement. Un fichier retiré du serveur peut rester dans les résultats pendant des semaines, et dans les caches pendant plus longtemps encore. La vraie protection commence avant la mise en ligne, pas après la découverte.

La prochaine fois que vous tapez votre propre nom de domaine dans Google, demandez-vous ce que vous cherchez vraiment. Si la réponse est « je veux être rassuré », tapez plutôt site:votredomaine.com intitle:"index of". Vous serez peut-être moins rassuré. Mais vous saurez.