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

Le Google Dorking, ou Google Hacking si vous préférez, c'est l'art de transformer le moteur de recherche le plus utilisé du monde en outil de reconnaissance. Ce n'est pas un film. C'est une technique, simple sur le papier, mais redoutable en pratique, qui permet de retrouver des fichiers et des informations que personne n'aurait dû laisser traîner sur la toile. Et si la plupart des articles se contentent de lister les opérateurs comme filetype: ou intitle:, peu abordent ce qui m'intéresse ici : comment cette technique s'articule avec l'état actuel de Google, en 2026, et surtout, comment s'en servir pour se défendre, pas seulement pour attaquer.

Le Google Dorking : bien plus qu'une recherche avancée

Vous avez probablement déjà utilisé des guillemets pour une recherche exacte, ou un signe moins pour exclure un mot. Le Google Dorking pousse cette logique à l'extrême. Il ne s'agit plus de trouver une page web, mais de trouver des fragments de système d'information. Des fichiers de configuration, des sauvegardes de bases de données, des mots de passe stockés en clair dans des documents PDF, des caméras de surveillance accessibles sans mot de passe... Tout cela est indexé par Google. Et tout cela est trouvable avec la bonne requête.

Mon introduction là-dessus date de 2019. J'étais tombé, par pur hasard, sur une requête qui listait des fichiers de sauvegarde d'un site de e-commerce français. Rien d'extraordinaire, pas de fuite massive. Mais le simple fait de voir cette structure de fichiers exposée m'a ouvert les yeux. Ce n'était pas un "hack" au sens où on l'imagine. C'était juste une recherche. Une recherche qui aurait pu permettre à quelqu'un de plus mal intentionné de télécharger une base de données clients.

Les opérateurs de base

Pour comprendre le dorking, il faut d'abord maîtriser le vocabulaire. Sans ça, on est vite perdu. Voici l'essentiel, que vous trouverez dans 90% des tutoriels, mais je vous le donne avec ma sauce :

• site: — Restreint la recherche à un domaine. Ex : site:votre-domaine.fr
• filetype: — Recherche un type de fichier précis. Ex : filetype:sql
• intitle: — Trouve une page dont le titre contient le mot-clé. Ex : intitle:"index of"
• inurl: — Recherche dans l'URL. Ex : inurl:admin
• intext: ou allintext: — Recherche dans le corps de la page.
• cache: — Affiche la version en cache d'une page. Il est par ailleurs presque mort depuis les restrictions de 2023.

Ce sont les briques de base. Mais le vrai pouvoir du dorking vient de la combinaison de ces opérateurs. C'est là que ça devient intéressant. "Une seule brique ne fait pas un mur", et une requête seule ne fait pas une bonne reconnaissance.

Exemples concrets pour vos premiers pas

Voici quelques exemples que j'utilise lors de mes audits. Je vous conseille de les tester sur votre propre domaine, pas sur celui des autres. C'est plus sûr pour vous, et tout aussi instructif :

• site:mon-domaine.fr filetype:pdf — Pour lister tous les PDF publics. Vous seriez surpris de ce qu'on y trouve parfois.
• site:mon-domaine.fr intitle:"index of" — Pour découvrir des listes de fichiers ouvertes sur un serveur. Un classique.
• site:mon-domaine.fr ext:log — Pour trouver des fichiers de log exposés. Une mine d'or potentielle pour un attaquant.

En 2021, lors d'un audit pour un petit client dans le secteur de la santé, cette simple requête site:son-domaine.fr filetype:xlsx m'avait remonté un fichier Excel contenant les noms et dates de rendez-vous des patients. Ce n'était pas un piratage. C'était juste un fichier placé dans un dossier public du site. Résultat : une mise en demeure de la CNIL et une refonte complète de leur arborescence. Cette erreur leur a coûté 3 mois de travail et beaucoup de crédibilité. Et tout ça parce que quelqu'un avait fait un "glisser-déposer" un peu trop rapide.

Franchement, ce type de découverte est devenu la norme dans mon métier. La plupart des "fuites" ne viennent pas de hackers surpuissants, mais de négligences humaines. Et le Google Dorking n'est que la lampe de poche qui révèle ces négligences.

Les limites actuelles de Google en 2026

Il serait malhonnête de vous vendre le Google Dorking comme une solution miracle sans évoquer les changements récents. En 2023 et 2024, Google a considérablement muselé son moteur. Des opérateurs comme cache: et link: sont devenus obsolètes ou inopérants. La pagination a été également restreinte, rendant l'exploration exhaustive des résultats difficile. C'est un vrai problème pour ceux qui, comme moi, utilisent ces opérateurs quotidiennement.

Le problème ? Google, en quête de résultats "pertinents" et en lutte contre le spam, a réduit les fonctionnalités avancées. Le géant de Mountain View a pris cette décision pour éviter que ses serveurs soient utilisés comme de simples outils de scraping. Résultat : le dorking "à l'ancienne" est moins efficace. Et si je ne m'adapte pas, je perds un outil.

Quelles alternatives pour contourner ces restrictions ?

Face à ces restrictions, j'ai dû revoir ma copie. Il y a trois alternatives principales que j'utilise désormais en complément de Google :

• Bing — Il supporte encore des opérateurs que Google a abandonnés. C'est un backup fiable, même si l'indexation est moins complète.
• Shodan — Ce n'est pas un moteur de recherche classique. Il scanne l'ensemble de l'internet et catalogue les serveurs et leurs services. C'est plus technique, mais c'est un complément indispensable.
• GitHub Code Search — Pour chercher des secrets (clés API, mots de passe) directement dans le code source public. Une mine d'or, mais aussi un terrain glissant.

Et puis, il y a l'option de l'automatisation. Après des mois de tâtonnements, j'ai fini par développer un script Python qui utilise googlesearch-python pour lancer des dorks en masse. C'est un gain de temps certain, mais attention : Google déteste ça. J'ai vu des IP se faire bloquer en quelques heures. Il faut être prudent, espacer les requêtes et utiliser des proxies si vous voulez aller loin. Le jeu en vaut la chandelle pour les audits, mais c'est un chemin semé d'embûches.

L'usage défensif du dorking : l'angle que tout le monde oublie

On parle toujours du dorking comme d'une technique de hacking. C'est une erreur. Dans mon travail, je l'utilise principalement pour la défense. C'est un outil d'audit de surface d'attaque. L'idée est simple : si vous ne cherchez pas vos propres failles, quelqu'un d'autre le fera. Et il pourrait être moins sympa que vous.

Méthodologie d'audit en 4 étapes

Voici comment je procède pour un audit défensif complet d'un domaine. C'est une méthode que j'ai affinée au fil de mes 200+ audits, et elle a fait ses preuves :

1. Cartographie des fichiers sensibles — Je commence par lister tous les types de fichiers qui ne devraient pas être publics. site:domaine.fr (filetype:pdf OR filetype:xlsx OR filetype:docx). Je cloisonne par type, car chaque fichier a sa propre logique de fuite.
2. Détection des sous-domaines oubliés — site:*.domaine.fr peut révéler un sous-domaine de test, un vieux serveur oublié, ou un portail de gestion exposé.
3. Recherche de secrets et de fichers de configuration — site:domaine.fr ext:env OR ext:json ou intitle:"index of" intext:"config". C'est ici que je trouve les mots de passe de bases de données en clair.
4. Examen des pages d'administration — site:domaine.fr inurl:admin ou inurl:login. Et là, je vérifie si ces pages sont protégées par une simple authentification HTTP ou pire, rien du tout.

Cette méthode n'est pas infaillible. Elle a ses angles morts, notamment sur les sites rendus dynamiquement via JavaScript. Mais elle permet de régler 70% des problèmes les plus courants. Et les 30% restants, c'est une autre histoire.

Cas concret : une fuite de 18 Go

L'année dernière, j'ai été mandaté par une PME qui venait d'être victime d'un rançongiciel. Avant de payer quoi que ce soit, ils voulaient savoir comment les attaquants étaient entrés. En 2 jours, une simple recherche site:leur-domaine.fr filetype:bak a révélé une sauvegarde complète de leur base de données, datant de trois ans, sur un serveur de fichiers public. Un serveur qui avait été configuré par un prestataire pour un projet ponctuel, et qui était resté accessible depuis. La fuite faisait 18 Go. Je n'ai pas eu besoin de chercher plus loin. L'intrusion, c'était par là. Le point d'entrée était un fichier .bak. Une sauvegarde. Personne n'y avait pensé.

Cet exemple illustre parfaitement le problème : une négligence de configuration peut ruiner des années d'efforts de sécurité. Avouons-le, les pare-feu et les antivirus ne servent à rien si un serveur de fichiers est ouvert en lecture pour tout le monde. Le dorking n'a rien "hacké" ; il a juste lu ce qui était déjà public.

Le cadre juridique français et européen : où est la ligne rouge ?

La question juridique est celle qu'on me pose le plus souvent en formation. "Vous êtes sûr que c'est légal de faire ça ?" La réponse est nuancée, et c'est là que ça se corse.

En France, la loi Godfrain (loi n°88-19 du 5 janvier 1988) relative à la fraude informatique réprime l'accès frauduleux à un système de traitement automatisé de données. Le fait de "consulter" des fichiers publics via Google n'est pas, en soi, un accès frauduleux. C'est la même chose que lire un journal. En revanche, si vous téléchargez ces fichiers et les utilisez pour porter atteinte à leurs propriétaires, là, ça devient un délit. Tout comme le fait de modifier des données ou de les détourner.

Le RGPD ajoute une couche de complexité supplémentaire. Si vous collectez des données personnelles via un dork, même involontairement, vous êtes soumis à son régime. Une fuite de noms et d'adresses e-mail est une violation de données. La vendre, ou même la partager, peut vous coûter très cher.

La divulgation responsable, un impératif

Quand je tombe sur une faille via un dork, je ne la publie pas sur Twitter. Ni sur un forum. J'applique une politique de divulgation responsable (coordinated disclosure). Concrètement, voici ce que je fais :

• Je note les preuves (captures d'écran, URL exacte) sans télécharger plus que nécessaire.
• J'identifie le contact en charge de la sécurité chez le propriétaire du site.
• J'envoie un e-mail détaillé, avec un délai de réponse de 90 jours.
• Je ne publie rien avant l'expiration de ce délai.

Cette approche est la seule qui soit viable professionnellement. Non seulement elle protège les victimes, mais elle me protège aussi. L'anecdote du "bon pirate" qui révèle tout sur un forum est un mythe, et un moyen rapide de se retrouver en garde à vue.

Bon, soyons clairs : cette méthode n'est pas parfaite. J'ai déjà envoyé des e-mails qui sont restés sans réponse pendant des mois. Le délai de 90 jours est parfois impossible à tenir, et il faut alors s'armer de patience et de diplomatie.

Automatiser ses recherches : Python et OSINT

La recherche manuelle a ses limites. Quand on doit vérifier 50 domaines, il faut automatiser. C'est là que Python entre en jeu. Pas besoin d'être un développeur chevronné pour ça. Quelques lignes de code suffisent.

Un script Python simple et efficace

Voici un exemple basique de script que j'utilise pour lancer des requêtes en série. Il est volontairement simple pour être adapté :

import googlesearch
import time

Liste des dorks à exécuter
dorks = [
    'site:example.com filetype:pdf',
    'site:example.com intitle:"index of"',
    'site:example.com ext:sql',
]

for dork in dorks:
    try:
Effectuer la recherche
        results = googlesearch.search(dork, num_results=10)
        print(f"Résultats pour : {dork}")
        for url in results:
            print(f"  - {url}")
    except Exception as e:
        print(f"Erreur pour {dork}: {e}")
    
Délai pour éviter le blocage
    time.sleep(15)

Ce script est un outil de démonstration. Il ne remplace pas une vraie plateforme d'OSINT. Et je vous conseille de l'adapter à vos besoins. Si vous voulez aller plus loin, vous pouvez l'intégrer avec des APIs comme celles de Shodan ou de Censys pour enrichir vos résultats. Vous pouvez aussi utiliser des bibliothèques comme Requests et BeautifulSoup pour parser les pages trouvées et en extraire des métadonnées.

Le risque principal de l'automatisation, je l'ai déjà dit, c'est le blocage IP. Pour limiter les dégâts, j'ai appris à mes dépens qu'il faut espacer les requêtes. 15 secondes, c'est un minimum. Et si vous voulez automatiser à grande échelle, prévoyez un pool de proxies résidentiels. C'est un coût, mais c'est le prix de la tranquillité.

Les fichiers les plus exposés : une expérience empirique

Après des années à fouiller les recoins cachés d'Internet, j'ai fini par établir un classement informel des fichiers les plus fréquemment exposés. Ce n'est pas une étude scientifique, juste mon retour d'expérience sur des centaines d'audits. Et il y a des surprises.

Ce que ce tableau ne montre pas, c'est le ratio. Les fichiers .sql sont rares, mais ils sont une mine d'or quand on les trouve. Les fichiers .docx sont plus courants, mais moins intéressants. Le risque n'est pas lié qu'à la fréquence, mais à l'impact potentiel. Je préfère toujours chercher un fichier .env bien placé que 100 PDF inoffensifs.

Pourquoi cette disparité ? Parce que les développeurs oublient souvent de retirer les fichiers de configuration du serveur web après le déploiement. Ils sont dans le dossier public, par défaut. Et ça, c'est un problème que je rencontre dans près d'un tiers des audits que je mène. C'est un chiffre qui me semble stable, peu importe le secteur d'activité.

FAQ Google Dorking : les questions qu'on me pose souvent

Google Dorking est-il gratuit ?

Oui, le Google Dorking en lui-même est totalement gratuit. Les opérateurs de recherche sont utilisables sur le moteur de recherche Google sans aucun abonnement. Le coût, s'il y en a un, vient des outils qui automatisent les recherches ou qui analysent les résultats (comme certaines plateformes OSINT), mais la technique de base est accessible à tous.

Quel est un exemple typique de Google Dorking ?

Un exemple classique consiste à rechercher des fichiers de configuration exposés. La requête intitle:"index of" ".env" peut révéler des serveurs dont la racine n'est pas protégée, listant des fichiers sensibles. Le but est de trouver ce qui n'aurait jamais dû être indexé par le moteur de recherche.

Comment utiliser Google Dorking de manière éthique ?

Tout est une question de périmètre. Utiliser le dorking pour auditer votre propre infrastructure, ou celle d'un client avec un mandat écrit, est une pratique de sécurité légitime. Trouver une faille et la signaler de manière responsable est aussi une bonne pratique. En revanche, explorer les données d'un tiers sans autorisation, avec l'intention de les exploiter, est illégal et contraire à l'éthique. La frontière est claire.

Là où la technique rencontre l'éthique

Le Google Dorking n'est pas un hack. C'est un outil de recherche. Comme un pied-de-biche, il peut servir à forcer une porte ou à sauver une victime d'un incendie. Ce qui compte, ce n'est pas l'outil, c'est l'intention et le cadre. Et ce cadre, il faut se le fixer soi-même, avant de commencer à creuser.

Je me souviens d'un de mes premiers audits, où j'avais trouvé une vulnérabilité critique dans un site gouvernemental. Mon contact sur place avait poussé un soupir de soulagement. "Merci, vous nous avez évité un sacré problème." C'est pour ce genre de réaction que je fais ce métier. Pas pour le frisson.

Aujourd'hui, en 2026, avec des moteurs de recherche de plus en plus restrictifs et une législation de plus en plus stricte, le dorking est devenu un art de la précision. Il faut savoir s'adapter aux outils, anticiper les réponses de Google et, surtout, garder une éthique irréprochable. La prochaine fois que vous tapez une requête, posez-vous la question : "Est-ce que je cherche une information, ou est-ce que je cherche à m'introduire quelque part ?" La réponse déterminera si vous êtes un chercheur ou un intrus. Et cette nuance, elle fait toute la différence.