Google dorking : la technique secrète des hackers pour tout trouver

Vous tapez « Google Dorking » dans la barre de recherche et vous obtenez 50 000 résultats en 0,4 seconde. Mais ce que vous ne voyez pas, c'est que Google n'affiche qu'une infime partie de ce qu'il indexe réellement. Et c'est précisément là que le dorking entre en jeu : non pas pour chercher ce qui est visible, mais pour extraire ce qui ne devrait pas l'être.

J'utilise ces techniques depuis des années, d'abord par curiosité mal placée, ensuite dans un cadre professionnel pour auditer la sécurité de mes propres serveurs. Et franchement, ce que j'ai trouvé en chemin m'a fait froid dans le dos. Voici ce que j'ai appris — sans langue de bois.

Qu'est-ce que le Google Dorking, exactement ?

Le Google Dorking, c'est l'art d'utiliser les opérateurs de recherche avancée de Google pour trouver des informations que personne n'a intentionnellement publiées. Pas des mots-clés sophistiqués, non. Des requêtes précises qui exploitent la façon dont Google indexe le web.

Prenons un exemple concret. Si je cherche filetype:env DB_PASSWORD, je vais potentiellement trouver des fichiers de configuration exposés contenant des identifiants de bases de données. C'est aussi simple que ça. Et ça marche encore, en 2026.

Quand j'ai commencé à m'y intéresser il y a quelques années, mon premier réflexe a été de tester sur mon propre site. Résultat ? Un fichier de sauvegarde datant de trois ans, accessible sans authentification. Une erreur de ma part, corrigée en dix minutes, mais qui aurait pu coûter cher.

Pourquoi Google indexe-t-il des données privées ?

La réponse est dérangeante : parce que Google ne fait pas de différence entre une page publique et une page qui aurait dû rester privée. Si un fichier est accessible via une URL directe, le crawler de Google peut le suivre s'il est lié quelque part — ou même simplement deviné. Et une fois indexé, il reste dans le cache longtemps après avoir été retiré du serveur.

Le problème ne vient pas de Google. Il vient de la configuration des serveurs, des erreurs humaines (mot de passe en dur dans un fichier de config, backup laissé dans le répertoire racine), et d'une méconnaissance générale des administrateurs systèmes. Le dorking ne fait que révéler ce qui est déjà là.

Les opérateurs avancés les plus puissants

La base, tout le monde la connaît : site:, filetype:, intitle:. Mais c'est la combinaison qui fait la différence. Voici les opérateurs que j'utilise réellement dans mes audits, avec des exemples qui ont du sens.

Notez bien : la syntaxe française et anglaise varie selon les moteurs. Sous Google, filetype: fonctionne aussi bien que ext:. Sous Bing, l'opérateur inbody: existe, ce qui n'est pas le cas chez Google. Ces différences ont leur importance quand on cherche des données non indexées par Google.

inurl: et intitle: pour cibler des structures

inurl: cherche dans l'URL, intitle: dans le titre de la page. L'intérêt ? Les URL révèlent souvent la structure d'un site, et donc ses points faibles.

Exemple : inurl:/admin/ intitle:login peut révéler des interfaces d'administration publiquement accessibles. Sur un site de e-commerce que j'auditais, cette requête a fait remonter une page de connexion à un back-office sans protection par IP. Inutile de préciser que le client était content de l'apprendre avant les autres.

Autre exemple utile : intitle:index.of — cette requête trouve les serveurs qui listent leur contenu sans page d'index. Une mine d'or pour l'OSINT, et une plaie pour ceux qui l'ignorent.

filetype: et ext: pour cibler des formats sensibles

filetype:pdf, filetype:xls, filetype:sql… Chaque format a son intérêt. Un fichier SQL, par exemple, contient potentiellement l'intégralité d'une base de données. Un fichier .env, des identifiants. Un .xls, des données clients.

Je me souviens d'une recherche anodine : filetype:sql "INSERT INTO" "users" — pour comprendre la structure de bases exposées. Résultat : plusieurs dizaines de fichiers contenant des données personnelles complètes, indexées par Google depuis des années. Aucun exploit technique, juste une requête bien construite.

Attention cependant : Google filtre certains résultats et peut censurer des pages sensibles. Mais une bonne partie passe encore à travers les mailles du filet.

Exemples de requêtes dork concrètes

Voici quelques requêtes que j'ai testées dans des environnements contrôlés — et que vous pouvez essayer sur des sites qui vous appartiennent ou avec autorisation. Pas sur des cibles tierces. Vous êtes prévenu.

• site:monsite.fr filetype:log — trouver des fichiers de logs exposés, souvent remplis d'IP et d'URLs internes.
• site:monsite.fr intext:"password" filetype:txt — des fichiers texte contenant le mot "password". Oui, ça existe encore.
• inurl:wp-content/uploads filetype:sql — des sauvegardes de bases WordPress dans le dossier public des uploads. Un classique.
• intitle:"index.of" "backup" — des serveurs exposant leurs sauvegardes sans page d'index. La quantité de données accessibles est vertigineuse.

Une mise en garde : ces requêtes fonctionnent, mais les résultats varient énormément selon la date, la géolocalisation et les filtres de Google. Ne vous attendez pas à des résultats identiques d'une semaine à l'autre.

Google Dorking, OSINT et veille concurrentielle

Le dorking n'est pas qu'un outil offensif. En OSINT (renseignement d'open source), il permet de cartographier une entité avant une intervention. En veille concurrentielle, de détecter des informations que vos concurrents n'ont pas correctement protégées.

Prenons un scénario : vous voulez savoir si un concurrent expose des documents internes. Une requête comme site:concurrent.com filetype:pdf "confidentiel" peut suffire. J'ai vu des rapports de stratégie commerciale indexés publiquement pendant des mois. Sans aucun piratage. Juste une URL oubliée dans une page de ressources.

Mon conseil : utilisez ces techniques pour auditer votre propre présence en ligne. C'est le meilleur moyen de comprendre ce qu'un internaute déterminé peut trouver sur vous. Et si vous trouvez quelque chose, corrigez-le immédiatement : retirez le fichier, ajoutez une règle dans robots.txt (même si c'est imparfait), et vérifiez qu'aucun lien externe ne pointe vers la ressource.

Comment construire une requête dork efficace ?

La plupart des gens se contentent d'empiler des opérateurs au hasard. Résultat : des milliers de résultats inexploitables. La méthode que j'utilise tient en trois étapes.

Premièrement, définir l'objectif. Qu'est-ce que vous cherchez ? Un type de fichier ? Une information précise ? Une structure de site ? Sans objectif clair, vous perdez du temps.

Deuxièmement, choisir les opérateurs adaptés. filetype: pour les formats, inurl: pour les structures, intitle: pour les pages spécifiques, intext: pour le contenu. Combinez-en deux ou trois maximum. Au-delà, vous passez à côté de résultats pertinents.

Troisièmement, itérer. Les premiers résultats sont rarement les bons. Modifiez un mot, changez un opérateur, affinez la portée avec site:. En général, au bout de cinq ou six tentatives, vous obtenez ce que vous cherchez.

Une question que je me fais souvent poser : faut-il utiliser un outil pour automatiser les dorks ? Certaines interfaces graphiques existent, sur ordinateur comme sur mobile, qui centralisent des listes de requêtes. C'est pratique pour un usage récurrent, mais rien ne vaut la compréhension manuelle des opérateurs. Un outil qui génère des dorks sans que vous compreniez pourquoi, c'est une boîte noire qui peut vous mener en eau trouble.

Dorking et respect du cadre légal

Le droit est clair sur un point : consulter une page accessible publiquement n'est pas illégal en soi. Mais dès que vous franchissez la ligne — exploitation d'une faille, tentative d'accès non autorisé, téléchargement massif de données personnelles — vous entrez dans la zone rouge.

Le RGPD, côté données personnelles, est un marteau : collecter et traiter des données personnelles sans base légale expose à des sanctions lourdes. Et les tribunaux ne se privent pas de condamner les curieux trop entreprenants.

Mon opinion sur ce sujet : si vous utilisez ces techniques, faites-le exclusivement sur vos propres systèmes ou dans un cadre d'audit autorisé par écrit. Tout le reste est une prise de risque inutile — et potentiellement coûteuse.

Limites et contre-mesures face aux dorks

Le dorking a ses limites. Google ne montre pas tout : il censure certaines pages, limite les résultats pour les recherches trop fines, et son index est une photographie du web, pas un miroir en temps réel.

Les sites peuvent aussi se protéger. robots.txt empêche l'indexation de certaines sections (mais ne bloque que Google et ses semblables, pas les autres moteurs ni les accès directs). L'authentification, la protection par IP et la non-référençabilité des URL sont plus efficaces. Mais rien ne remplace une bonne hygiène : ne jamais laisser de fichiers sensibles dans un répertoire public, que ce soit en clair ou dans une archive.

Une contre-mesure que je recommande systématiquement : effectuer des recherches dorks périodiques sur son propre nom de domaine. Pour mes clients, je recommande cette vérification trimestrielle. Le temps qu'un problème soit détecté par un tiers, il est déjà trop tard.

Dorking sur les moteurs alternatifs

Google n'est pas le seul moteur à pouvoir être « dorké ». Bing possède sa propre syntaxe, parfois plus permissive, avec des opérateurs comme inbody:. Shodan, lui, indexe les serveurs et périphériques connectés : une recherche par port ou par service donne des résultats que Google ne montrera jamais. Si vous faites de l'OSINT un peu sérieux, vous finirez tôt ou tard par ajouter Shodan à votre panoplie.

Le format d'une URL (site: chez Google, domain: chez Bing) varie également. Il faut donc adapter sa syntaxe selon le moteur. C'est une contrainte, mais aussi une opportunité : ce que Google filtre, Bing l'affiche parfois.

Bref, le Google Dorking n'est qu'un outil parmi d'autres. Mais c'est celui sur lequel vous pouvez vous appuyer sans infrastructure particulière, avec un simple navigateur.

En fin de compte, la question la plus utile n'est pas « comment faire ? » — c'est « pourquoi votre serveur expose-t-il des fichiers sensibles ? » Le dorking révèle ; il ne cause pas. La prochaine fois que vous taperez une requête dork, rappelez-vous que quelque part, une URL oubliée pourrait répondre présente. Et que ce pourrait être la vôtre.