Google dorking : 12 requêtes qui révèlent des failles cachées

Un client m'appelle un mardi matin, la voix un peu blanche. Il a tapé son propre nom de domaine dans Google, suivi de deux mots, et il est tombé sur un fichier .sql de 40 Mo qui contenait sa base clients en clair. Le fichier était en ligne depuis onze mois. Personne ne l'avait trouvé avant lui. Ni son prestataire, ni son agence, ni moi.

Ce jour-là, j'ai compris une chose simple : le google dorking n'est pas une technique de hacker, c'est un moteur de recherche qu'on utilise correctement. Et la plupart des entreprises découvrent son existence quand il est trop tard.

Qu'est-ce que le google dorking, vraiment ?

La question qu'on me pose le plus souvent, c'est : « Qu'est-ce que les Google Dorks ? » La réponse tient en une phrase, mais elle mérite un détour.

La définition, sans jargon

Un Google Dork est une requête de recherche construite avec les opérateurs avancés du moteur (site:, filetype:, intitle:, inurl:, etc.) dans le but de faire remonter des résultats très spécifiques. Le google dorking, ou Google Hacking, c'est l'usage systématique de ces requêtes pour repérer ce qui traîne.

Google a mis ces opérateurs là pour le commun des mortels. Un documentaliste qui cherche un PDF sur un site précis utilise déjà du dorking sans le savoir. La différence, c'est l'intention et la méthode : chercher les fichiers qu'on n'aurait pas dû laisser accessibles.

Le dorking n'est pas un piratage

Point important, souvent mal compris. Le dorking ne casse rien. Il ne force aucune porte. Il constate qu'une porte est restée ouverte. C'est la différence entre un cambrioleur et quelqu'un qui marche dans la rue et remarque qu'une vitrine est béante.

Ça ne rend pas l'acte anodin pour autant. En France, consulter des données personnelles qu'on n'a pas le droit de voir, même lorsqu'elles sont accessibles publiquement, peut tomber sous l'article 226-17 du code pénal ou les règles du RGPD selon l'usage qu'on en fait. J'y reviens plus bas.

Pouvez-vous me donner des exemples de Google Dorks ?

Oui, et je vous préviens : les plus simples sont les plus efficaces. Ceux qui impressionnent dans les vidéos YouTube ne servent pas à grand-chose en pratique.

Les opérateurs à connaître par cœur

Opérateur	Ce qu'il fait	Exemple concret
site:	Restreint à un domaine	site:monentreprise.fr filetype:pdf
filetype:	Filtre par extension	filetype:sql "mot de passe"
intitle:	Cherche dans le titre de la page	intitle:"index of" backup
inurl:	Cherche dans l'URL	inurl:admin site:monentreprise.fr
intext:	Cherche dans le corps de la page	intext:"confidentiel"
cache:	Version en cache (de plus en plus limitée)	cache:monentreprise.fr

Trois requêtes qui m'ont déjà servi

Un audit que j'ai mené pour une PME de logistique en 2024 : première requête, site:leur-domaine.fr filetype:xlsx. Résultat, un fichier de suivi RH avec les salaires bruts de vingt-deux personnes, accessible sans authentification. Le fichier avait été poussé sur un serveur de test oublié.

Deuxième cas, un site e-commerce. intitle:"index of" inurl:backup a remonté un répertoire de sauvegardes automatiques nommées par date. Un des fichiers contenait un export complet de la base produits et clients.

Troisième cas, moins spectaculaire mais tout aussi gênant : site:domaine.fr inurl:wp-content/debug.log. Un fichier de log WordPress accessible publiquement, avec les chemins serveur et les traces d'erreurs qui allaient bien au-delà du raisonnable.

• Ces requêtes tiennent en deux minutes à taper.
• Elles ne demandent aucune compétence technique particulière.
• Elles rendent un résultat immédiat, ce qui est justement le problème.

Voilà le nœud : la barrière à l'entrée est quasi nulle. C'est pour ça qu'il faut les connaître avant que quelqu'un d'autre ne les tape sur votre domaine.

Comment savoir si mon Google est piraté ?

Cette question revient souvent telle quelle, et elle mérite une réponse honnête : Google n'est pas piraté, votre site l'est peut-être.

Quand un site est compromis, les attaquants injectent des pages cachées (souvent du spam pharmaceutique ou des redirections) et ils les laissent indexées par Google. Résultat : votre nom apparaît dans les résultats de recherche associé à des contenus que vous n'avez jamais publiés. Ce n'est pas Google qui a été piraté, c'est votre serveur.

Les signaux qui doivent vous alerter

• Des pages qui apparaissent dans les résultats Google mais que vous ne retrouvez pas dans votre back-office.
• Un trafic soudain de requêtes bizarres (médicaments, casino, contenu adulte) qui pointent vers votre domaine.
• Un message dans la Google Search Console signalant une action manuelle pour spam ou contenu piraté.
• Des redirections que vous n'avez pas configurées, visibles depuis un mobile ou depuis un autre pays.

Comment vérifier, concrètement

Ma méthode, dans l'ordre : d'abord site:votredomaine.fr dans Google, puis dans la Search Console la section « Couverture » pour repérer les URL indexées que vous ne reconnaissez pas. Ensuite, un site:votredomaine.fr inurl:shell ou inurl:upload pour voir si des scripts ont été déposés.

Un détail que j'ai appris à la dure : les pages injectées ne sont pas toujours visibles depuis votre navigateur. Elles sont parfois servies uniquement aux robots d'indexation ou aux visiteurs venus d'un autre pays. Il faut donc tester avec un agent utilisateur différent, ou comparer ce que renvoie le serveur à un utilisateur lambda et à un crawler.

Bref, si vous avez un doute, la Search Console est votre premier réflexe, pas un scanner miracle acheté en ligne.

Le dorking ne s'arrête pas à Google

Là, je vais être un peu cash : si votre audit se limite à Google, vous passez à côté de la moitié du problème.

Bing dispose des mêmes opérateurs essentiels (site:, filetype:, intitle:), avec parfois des résultats différents selon l'indexation. DuckDuckGo repose en grande partie sur Bing, donc peu d'intérêt propre, mais ça reste utile pour recouper. Et puis il y a un cran au-dessus, qui n'a plus rien à voir avec les moteurs de recherche classiques.

Shodan et Censys, l'autre face du dorking

Shodan indexe des appareils connectés, pas des pages web. Caméras IP, serveurs exposés, bases de données ouvertes sur internet. Les opérateurs sont différents (port:, country:, product:), mais la logique est la même : chercher ce qui ne devrait pas être visible.

Je me souviens d'un audit où une requête Shodan sur l'AS d'un client a remonté un serveur de messagerie avec un port de gestion ouvert à tous les vents. Le DSI m'a dit qu'il « ne savait pas que ce port était là ». C'est le genre de phrase qu'on n'oublie pas.

Pour le côté OSINT, le google dorking reste central, mais il faut le coupler à ces moteurs si vous voulez une vue complète de votre surface exposée.

Comment se protéger sans y passer ses nuits

La bonne nouvelle, c'est qu'un audit de base prend une heure et couvre l'essentiel. Le reste, c'est de la surveillance régulière.

• Restreindre l'accès aux fichiers sensibles : un .htaccess ou une règle serveur qui bloque les extensions sensibles (.sql, .bak, .log, .env). C'est la mesure la plus rentable.
• Ne pas laisser d'indexation ouverte sur les répertoires : un Options -Indexes côté Apache, ou l'équivalent côté Nginx, et les répertoires sans page d'accueil ne listent plus leurs fichiers.
• Surveiller avec des alertes Google : créez une alerte sur site:votredomaine.fr pour être notifié quand de nouvelles URL apparaissent. Imparfait, mais gratuit.
• Automatiser un scan mensuel : quelques requêtes répétées chaque mois, avec un rappel dans l'agenda, valent mieux qu'un audit annuel oublié.

Une erreur que j'ai faite sur mon propre site, en toute transparence : j'ai laissé un fichier .env en production pendant trois semaines parce que mon script de déploiement le recopiait sans le renommer. Trouvé par un ami à qui j'avais demandé de tester. Ça pique un peu.

Ce qu'on a le droit de faire, et ce qu'on n'a pas le droit

Dorker son propre domaine : aucun problème, c'est de l'hygiène numérique. Dorker le domaine d'un concurrent pour vérifier qu'il a laissé ses sauvegardes en clair : zone grise, à éviter. Dorker pour extraire des données personnelles et les réutiliser : infraction, point final.

La ligne de partage est simple à énoncer mais difficile à tenir : observer sans exploiter. Vous pouvez signaler à une entreprise qu'elle a exposé un fichier. Vous ne pouvez pas l'utiliser.

Et si vous voulez vous entraîner, faites-le sur des environnements prévus pour ça (les plateformes de type TryHackMe existent pour une raison), pas sur des sites en production au hasard.

Ce qu'il faut vraiment retenir

Le google dorking n'est pas une arme de hacker. C'est une compétence de base, aussi banale que savoir lire un fichier de log. La vraie question n'est pas de savoir si quelqu'un l'utilisera contre vous, mais quand quelqu'un tombera dessus par hasard, en cherchant tout autre chose.

Ce mardi-là, mon client a mis trois jours à faire supprimer son fichier .sql. Sa base était indexée depuis presque un an. Quand je lui ai demandé s'il ferait un audit régulier à l'avenir, il a répondu qu'il voulait surtout savoir combien de temps il avait perdu. Je n'ai pas eu le cœur de lui répondre précisément.

Une dernière chose : la requête la plus utile que vous tapiez aujourd'hui n'est pas dans cet article. C'est site:votredomaine.fr. Ça prend trente secondes. Vous n'aimerez peut-être pas ce que vous verrez.