Google Dorking : le guide des Google Dorks pour débutants

Qu'est-ce que le Google dorking ?

Le Google dorking consiste à utiliser des opérateurs de recherche avancés pour trouver des informations qu'un moteur de recherche a indexées mais que leur propriétaire n'avait jamais l'intention de publier. Un dork est l'une de ces requêtes. Au lieu de demander à Google de quoi parle une page, vous lui réclamez des pages ayant un type de fichier précis, un mot précis dans l'URL ou une expression précise dans le titre, et vous laissez les erreurs de configuration remonter à la surface.

Le nom vient de Johnny Long, qui a commencé à cataloguer en 2002 les requêtes exposant des systèmes sensibles, puis les a organisées dans la Google Hacking Database (GHDB) en 2004. Il a présenté ses travaux à Black Hat en 2004 et publié Google Hacking for Penetration Testers en 2005. Depuis 2010, la GHDB est maintenue par OffSec au sein de l'Exploit Database.

Voici le point que les débutants comprennent de travers. Le dorking n'exploite rien dans Google. Google fait parfaitement son travail : il a exploré une URL publique et indexé ce qu'il y a trouvé. La vulnérabilité est de l'autre côté, là où quelqu'un a laissé le listage de répertoires activé, poussé un fichier .env dans une racine web, ou déposé un rapport interne sur un serveur sans authentification avec un lien pointant dessus. Le dorking ne fait que vous donner un langage de requête pour trouver ce type d'erreur à grande échelle.

MITRE suit cela sous la tactique Reconnaissance, référence T1593.002, Search Engines, en décrivant comment les attaquants utilisent des « requêtes spécialisées pour chercher des fuites d'informations sensibles telles que des détails réseau ou des identifiants ». Les vrais attaquants s'en servent, et c'est précisément pour cela que les défenseurs doivent connaître la technique.

Les opérateurs de recherche Google qui comptent

Des dizaines d'opérateurs circulent dans les articles de blog. Huit d'entre eux font presque tout le travail. Apprenez ceux-là et vous pourrez construire n'importe quel dork dont vous aurez besoin.

Ceux que Google documente réellement

Il vaut la peine de savoir lesquels Google assume officiellement. Sa page officielle sur l'affinage des recherches ne documente que les guillemets d'expression exacte, site:, le signe moins pour l'exclusion, filetype: et les opérateurs de date before: et after:. Tout le reste du tableau ci-dessus n'est pas documenté.

Non documenté ne veut pas dire cassé. intitle:, inurl: et intext: fonctionnent depuis vingt ans et ne montrent aucun signe de disparition. Cela veut dire en revanche que Google ne vous doit rien si l'un d'eux change de comportement mardi prochain, ce qui arrive vraiment.

Les variantes préfixées méritent une ligne chacune. allintitle: et allinurl: exigent que tous les mots qui suivent correspondent au lieu d'un seul, ce qui rend service à l'occasion mais se combine mal avec les autres opérateurs. En pratique, vous utiliserez deux fois intitle: plutôt qu'une fois allintitle:.

Les opérateurs morts en 2026

C'est là que la plupart des aide-mémoire s'effondrent. Si un article liste encore ceux-ci, il a été copié plutôt que testé :

• cache: - disparu. Google a retiré son cache public en février 2024 et a supprimé l'opérateur avec lui. Search Liaison a confirmé publiquement la suppression. En septembre 2024, Google a ajouté des liens vers l'Internet Archive dans ses résultats comme remplacement partiel.
• link: - déprécié en 2017. Il renvoie encore quelque chose, mais l'échantillon est si fortement filtré que le résultat n'est exploitable pour rien.
• info: - retiré. Google expose désormais les mêmes informations sur une page via le panneau « À propos de ce résultat ».
• + et ~ - abandonnés tous les deux depuis des années. Utilisez les guillemets pour la correspondance exacte à la place de +.

Quand vous avez besoin d'une copie archivée d'une page qui a été nettoyée depuis, allez directement sur la Wayback Machine. Cette habitude est plus fiable que cache: ne l'a jamais été, parce que l'archive conserve un historique plutôt qu'un instantané unique.

Combiner les opérateurs : vos premiers vrais dorks

Un opérateur, c'est une recherche. Trois opérateurs, c'est un dork. Tout l'art consiste à empiler des contraintes jusqu'à ce que le bruit disparaisse, et le plus rapide pour le comprendre, c'est de construire une requête par étapes.

Supposons que vous testiez une entreprise et que vous vouliez savoir quels documents lui appartenant traînent dans l'index de Google. Commencez large :

site:example.com

Ce sont toutes les pages indexées du domaine, soit des milliers de résultats inutilisables sur une vraie entreprise. Restreignez aux documents plutôt qu'aux pages web :

site:example.com filetype:pdf

C'est mieux, mais un site d'entreprise publie des brochures et des fiches produit volontairement. Vous cherchez les documents publiés par accident : ajoutez une expression qui n'apparaît que sur des documents destinés à rester en interne :

site:example.com filetype:pdf "internal use only"

Retirez maintenant le sous-domaine qui héberge la bibliothèque marketing publique, puisque vous savez déjà ce qu'il contient :

site:example.com -site:downloads.example.com filetype:pdf "internal use only"

Quatre opérateurs, et l'ensemble des résultats est passé de milliers de pages à une liste que vous lisez en deux minutes. Cette progression, du large vers l'étroit avec une soustraction à la fin, est le schéma derrière tous les bons dorks.

Trois motifs à retenir

Une fois l'empilement assimilé, la plupart des dorks utiles prennent trois formes.

Le listage de répertoires. intitle:"index of" cible le titre de page qu'Apache et nginx génèrent quand la navigation dans les répertoires est laissée active sans fichier d'index. Ajoutez un mot-clé pour l'orienter : intitle:"index of" "backup". Ce seul dork est responsable d'une large part des expositions accidentelles sur Internet, et cela dure depuis vingt ans.

Les portails de connexion. inurl:admin et intitle:"login" trouvent les interfaces d'administration qui n'auraient jamais dû être exposées sur Internet. Sur une mission autorisée, cela cartographie rapidement la surface d'attaque, et cela révèle souvent un panneau de préproduction oublié qui tourne deux versions majeures derrière la production.

Les messages d'erreur. Une trace d'exécution dans l'index vous indique le framework, parfois la version, et occasionnellement un chemin de fichier sur le serveur. Chercher une chaîne d'erreur exacte accompagnée de site: est la façon de trouver les applications laissées en mode debug.

En pratique, la combinaison d'opérateurs compte moins que le mot-clé que vous lui donnez. N'importe qui sait lancer filetype:xlsx. Celui qui trouve quelque chose a lancé filetype:xlsx avec un mot qui n'apparaît que dans les modèles internes de la cible, et il a récupéré ce mot sur une page tout à fait ordinaire du site de cette même cible.

Un aide-mémoire de Google dorks fiable

Chaque dork ci-dessous n'utilise que des opérateurs dont le fonctionnement est confirmé en 2026. Lisez la colonne du milieu avant de copier celle de gauche : comprendre pourquoi un dork fonctionne est ce qui vous permettra d'écrire les vôtres.

Deux habitudes vous feront gagner du temps. D'abord, relancez le même dork sur Bing et DuckDuckGo quand Google revient vide, car les trois moteurs indexent des coins différents du web et Bing gère en plus ip: pour les recherches inversées par adresse IP. Ensuite, attendez-vous à un CAPTCHA si vous enchaînez vingt dorks d'affilée. C'est Google qui bride votre débit, pas qui vous bloque, et ralentir suffit à régler le problème. Les outils qui pulvérisent des centaines de requêtes par minute envoient votre IP dans une pause bien plus longue.

La Google Hacking Database

La Google Hacking Database est un index public et catégorisé de requêtes de recherche qui exposent des informations sensibles ou des systèmes vulnérables. Elle existe depuis 2004 et vit sur Exploit-DB, où chaque entrée est étiquetée, datée et créditée à la personne qui l'a soumise.

Les entrées sont regroupées selon ce qu'elles trouvent, et les noms de catégories en disent long sur la façon dont les systèmes échouent :

• Files Containing Passwords, Files Containing Usernames, Files Containing Juicy Info
• Sensitive Directories, Vulnerable Files, Vulnerable Servers
• Pages Containing Login Portals, Various Online Devices
• Error Messages, Web Server Detection, Footholds
• Advisories and Vulnerabilities, Network or Vulnerability Data, Sensitive Online Shopping Info

Servez-vous de la GHDB comme d'une source d'idées plutôt que d'une liste à exécuter. Beaucoup d'entrées anciennes visent des logiciels qui n'existent plus, et Google a discrètement cessé de faire correspondre une partie de la syntaxe. La valeur est dans le motif : lisez dix entrées de la catégorie « Vulnerable Servers » et vous commencerez à repérer quelles chaînes un produit donné place toujours dans ses titres, une connaissance que vous pourrez appliquer à ce que vous testez réellement.

Une opinion tranchée, puisqu'il faut bien que quelqu'un la formule : ignorez les listes « les 1000 meilleurs Google dorks ». Ce sont des copies de copies de la GHDB avec les opérateurs morts laissés dedans, et en parcourir une ne vous apprend rien d'autre qu'à coller du texte. Huit opérateurs et le raisonnement qui va avec vous mèneront plus loin que mille requêtes que vous n'avez pas écrites.

Le Google dorking en CTF et en reconnaissance bug bounty

Pour un joueur de CTF, le dorking apparaît à deux endroits. Les défis OSINT vous donnent un nom, un pseudo ou une photo et attendent que vous trouviez le reste : une requête site: bien visée sur les plateformes où les gens laissent fuiter des choses sur eux-mêmes battra n'importe quel outil. Les défis web cachent parfois un indice ou une ancienne version d'une page complètement en dehors de la machine du défi, et la Wayback Machine plus un dork site: vous y emmènent.

C'est en bug bounty que la reconnaissance par dorking rapporte vraiment. Le déroulé qui fonctionne ressemble à ceci :

1. Lisez le périmètre du programme et notez chaque domaine et chaque joker que vous avez le droit de toucher.
2. Lancez site:*.target.com -www pour énumérer gratuitement les sous-domaines que Google connaît déjà, avant même de résoudre le moindre enregistrement DNS.
3. Chassez les types de fichiers que personne ne publie volontairement : filetype:env, filetype:sql, filetype:log, filetype:bak.
4. Fouillez les plateformes de code : site:github.com "target.com" associé à des mots comme api_key, token ou les noms de projets internes de l'entreprise.
5. Regardez ce qu'une ancienne version du site exposait, puis vérifiez si le chemin est toujours actif.

Remarquez ce que cette liste ne contient pas : le moindre contact avec la cible. Tout ce qui précède interroge un tiers, et c'est pour cela que le dorking est classé en reconnaissance passive et qu'on peut le lancer sans risque avant l'ouverture d'une fenêtre de test. Dès l'instant où vous allez chercher une de ces URL directement, ou que vous commencez à forcer des chemins avec un outil comme Gobuster, vous passez en test actif et les règles changent complètement.

Le dorking se combine naturellement au reste d'une boîte à outils de reconnaissance plutôt qu'il ne la remplace. Notre sélection d'outils OSINT gratuits montre où l'énumération de sous-domaines, la recherche dans les fuites et l'extraction de métadonnées prennent le relais une fois que Google a donné tout ce qu'il avait.

Vérifier ce que Google sait de votre propre site

La moitié défensive de cette compétence prend dix minutes et constitue l'élément le plus utile de cet article pour quiconque administre un site web. Lancez ceci sur votre propre domaine, tout de suite :

site:yourdomain.com intitle:"index of"
site:yourdomain.com filetype:env
site:yourdomain.com filetype:sql OR filetype:bak OR filetype:log
site:yourdomain.com inurl:admin OR inurl:login
site:yourdomain.com "confidential" OR "internal use only"

Tout ce qui remonte est déjà public. Cela a été exploré, indexé et servi à quiconque le demandait, et supprimer le fichier aujourd'hui ne change rien à qui l'a lu hier.

Le DHS, le FBI et le NCTC ont publié un bulletin conjoint à ce sujet en juillet 2014, intitulé « Malicious Cyber Actors Use Advanced Search Techniques ». Il documente un cas d'octobre 2013 où des attaquants ont utilisé le dorking pour repérer des sites faisant tourner une version vulnérable d'un logiciel de forum, puis ont compromis 35 000 sites web et y ont créé des comptes administrateurs. Le bulletin recommandait de limiter ce qui est mis en ligne, de s'auto-auditer à l'aide de la GHDB et de faire retirer le contenu indexé via la Search Console.

Le piège du robots.txt

Le réflexe est d'ajouter le chemin sensible au robots.txt. Ne le faites pas. Deux problèmes, et tous les deux sont pires que ce que vous vouliez corriger.

Premièrement, robots.txt contrôle l'exploration, pas l'indexation. Une URL interdite peut toujours apparaître dans les résultats de Google si quoi que ce soit, n'importe où, pointe vers elle, car Google n'a jamais eu besoin d'explorer la page pour savoir qu'elle existe. La documentation de Google dit clairement que le robots.txt n'est pas un mécanisme pour tenir une page hors des résultats de recherche.

Deuxièmement, robots.txt est un fichier public. La toute première requête d'un hacker sur une nouvelle cible est /robots.txt, précisément parce que les administrateurs y listent obligeamment leurs répertoires les plus sensibles. Vous avez dessiné la carte au trésor et vous l'avez laissée sur le pas de la porte.

Ce qu'il faut faire à la place : posez une balise noindex ou un en-tête X-Robots-Tag sur les pages qui doivent rester hors de l'index, utilisez l'outil de suppression de la Search Console pour ce qui est déjà indexé, et mettez une vraie authentification devant tout ce qui est réellement sensible. Le listage de répertoires doit être désactivé sur tout serveur web de production, et un fichier .env ne devrait tout simplement jamais être accessible depuis une racine web.

Considérations légales et éthiques

Le Google dorking se situe dans une zone réellement grise, et la réponse honnête est que la requête ne pose pas de problème mais que ce que vous en faites ensuite peut en poser un. Le dork interroge Google. Agir sur le résultat touche le système de quelqu'un d'autre.

Là où vous êtes clairement en règle

• Auditer des domaines que vous possédez ou administrez
• Des missions couvertes par une autorisation signée qui nomme le domaine dans le périmètre
• Les programmes de bug bounty, dans le périmètre et selon les règles publiées par le programme
• Les compétitions CTF et les labs d'entraînement conçus pour la pratique
• La recherche en sécurité où vous signalez les découvertes sans télécharger ni rediffuser les données

Là où les gens s'attirent des ennuis

• Télécharger des données personnelles exposées « pour vérifier si elles sont vraies »
• Se connecter à un portail avec des identifiants trouvés dans un fichier indexé, même une seule fois, même pour confirmer qu'ils marchent
• Publier un dork qui désigne une organisation précise encore vulnérable, avant qu'elle n'ait eu le temps de corriger
• Automatiser des centaines de requêtes contre un domaine hors de toute autorisation

Si vous trouvez quelque chose d'exposé qui ne vous appartient pas, la bonne démarche est la divulgation responsable : contactez l'organisation, décrivez ce qui est public et comment vous l'avez trouvé, ne touchez pas aux données et laissez-lui le temps de corriger. Pour situer la reconnaissance dans une méthodologie structurée, le Web Security Testing Guide de l'OWASP documente en détail la phase de collecte d'informations.

Questions fréquentes