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

Voilà, c'est fait. Le voici, ce fameux « google dorking ». Un terme qui sonne comme un truc de hacker de film, avec des néons verts et des hoodies. La réalité est à la fois plus simple et plus inquiétante.

Google Dorking : l'art de trouver ce que Google n'aurait jamais dû indexer

Vous tapez une requête, Google vous renvoie des résultats. C'est le principe de base. Mais que se passe-t-il quand on transforme ce réflexe en scalpel ? Quand on demande à Google de chercher non pas des pages web, mais des fichiers de configuration, des mots de passe oubliés ou des sauvegardes de bases de données exposées ?

C'est exactement ce que fait le Google Dorking. Et c'est probablement l'une des compétences les plus sous-estimées en cybersécurité, à la fois pour attaquer et pour se défendre.

Pourquoi le Google Dorking mérite votre attention (même si vous n'êtes pas hacker)

Franchement, j'ai longtemps pensé que c'était un truc de script kiddie. Un truc pour les ados qui veulent impressionner leurs potes en affichant des lignes de commande mystérieuses.

Puis j'ai vu un collègue auditeur retrouver, en moins de dix minutes, un fichier de sauvegarde d'une base clients d'une PME française. Pas une petite boîte anonyme. Une entreprise avec un site web professionnel, des mentions légales et tout le tintouin.

Ce fichier était en accès libre, indexé par Google, parce que quelqu'un avait mis une sauvegarde dans un dossier mal configuré sur le serveur web. La requête ? Quelque chose comme `filetype:sql "BACKUP" site:entreprise.fr`. Pas de magie. Pas de hack. Juste la capacité de poser la bonne question.

Bref. Depuis ce jour, j'ai arrêté de rigoler.

Le fonctionnement : bien plus que des guillemets

Le Google Dorking repose sur une poignée d'opérateurs relativement simples à maîtriser. Le problème, c'est que la plupart des gens s'arrêtent à `filetype:` et `inurl:`, et c'est là que ça devient intéressant.

Les opérateurs de base, et ce qu'ils changent vraiment

Opérateur	Fonction	Exemple concret	Ce que ça révèle
`filetype:`	Filtre les résultats par type de fichier	`filetype:env`	Fichiers de configuration avec souvent des clés API
`inurl:`	Limite aux résultats contenant un terme dans l'URL	`inurl:admin`	Interfaces d'administration non protégées
`intitle:`	Cherche un terme dans le titre de la page	`intitle:"index of"`	Listings de répertoires ouverts
`site:`	Restreint au domaine précisé	`site:mon-site.fr filetype:log`	Fichiers de logs exposés
`intext:`	Cherche un terme dans le corps de la page	`intext:"password" filetype:xlsx`	Fichiers Excel contenant des identifiants
`cache:`	Affiche la version en cache de Google	`cache:mon-site.fr`	Anciennes versions de pages supprimées

Bien sûr. Mais le vrai pouvoir, c'est la combinaison. Personne ne cherche juste `filetype:pdf "mot de passe"`. On combine trois ou quatre opérateurs pour affiner.

Prenons un exemple tiré d'un audit que j'ai réalisé l'an dernier pour un client dans la logistique.

La requête initiale était simple :

`site:client-logistique.fr filetype:xlsx`

Résultat : 14 fichiers Excel indexés. Aucun n'était censé être là. Le plus intéressant était une liste de fournisseurs avec leurs coordonnées bancaires complètes. Un fichier de 2023, toujours en ligne parce que personne ne l'avait retiré du serveur après l'avoir utilisé.

On a enchaîné avec :

`site:client-logistique.fr intext:"SMTP" filetype:log`

Et là, surprise. Un fichier de log avec ce qui semblait être des identifiants SMTP en clair. On a pu changer le mot de passe avant que quelqu'un d'autre ne le trouve.

L'erreur classique des débutants, et comment l'éviter

Quand j'ai commencé à m'intéresser sérieusement au dorking, j'ai fait une erreur monumentale. J'ai lancé des requêtes trop larges, sans domaine cible. `filetype:sql "password"` — et bien sûr, je suis tombé sur des résultats du monde entier. Inutilisable. Illisible. Et potentiellement problématique, parce que je regardais des fichiers qui n'étaient pas les miens.

La différence entre une recherche utile et une recherche hasardeuse, c'est le ciblage. On ne commence pas par chercher tout et n'importe quoi. On commence par chercher son propre domaine, ou celui d'un client pour lequel on a un mandat d'audit écrit.

La liste des dorks "génériques" qu'on trouve sur Internet (les fameux "Google Dorks" qu'on peut télécharger en PDF) est un piège. Elle donne l'illusion de la connaissance, mais sans contexte, elle ne produit que du bruit.

Dorking défensif : l'audit de sa propre exposition

C'est ici que le bât blesse, et c'est pourtant l'usage le plus légitime.

Le principe est simple : si un attaquant peut trouver vos fichiers sensibles via Google, vous devez les trouver avant lui.

J'ai mis en place une routine d'audit pour mon propre serveur et celui de quelques clients. Elle prend environ 30 minutes par mois, et elle se décompose ainsi :

• Recherche de fichiers par type : `filetype:sql`, `filetype:env`, `filetype:bak`, `filetype:conf`, `filetype:ini`. Dans les faits, les fichiers `.env` et `.bak` sont les plus dangereux. Les premiers parce qu'ils contiennent les identifiants de connexion, les seconds parce qu'on les oublie une fois la sauvegarde faite.
• Recherche de répertoires ouverts : `intitle:"index of" site:mondomaine.fr`. Un répertoire sans page d'accueil par défaut affiche souvent la liste complète de ses fichiers.
• Recherche de pages d'administration : `inurl:admin`, `inurl:login`, `inurl:backup`.
• Recherche de données personnelles : `intext:"RIB"`, `intext:"numéro de sécurité sociale"`, `intext:"adresse"` — combinés avec le domaine.

Le résultat de cet audit ? Sur un de mes serveurs, j'ai découvert un dossier `/backup/` avec une archive de 4 Go datant de deux ans. Personne ne savait qu'il était accessible. Google ne l'avait pas encore indexé, mais un attaquant qui aurait deviné l'URL l'aurait trouvé facilement.

Le problème, c'est que la plupart des entreprises ne font pas cet audit. Elles découvrent le problème quand quelqu'un d'autre le trouve. Résultat : une fuite de données qui aurait pu être évitée avec 30 minutes de requêtes ciblées par mois.

Les limites du dorking en 2026, et les alternatives

Avouons-le : le Google Dorking n'est plus ce qu'il était.

Google a progressivement réduit la prise en charge de certains opérateurs. Les résultats sont moins précis qu'il y a cinq ou dix ans. La recherche `filetype:` fonctionne toujours, mais elle est plus capricieuse. `cache:` est devenue pratiquement inutilisable. Et Google a commencé à demander des captchas après un certain nombre de requêtes automatisées.

Ce n'est pas une raison pour abandonner. C'est une raison pour diversifier.

Bing reste étonnamment efficace pour certaines recherches de fichiers. Il indexe différemment, et parfois mieux, certains types de contenus. Shodan est un autre monde : il ne cherche pas dans Google, mais dans les périphériques connectés à Internet. Pour trouver une base de données MongoDB exposée ou une caméra de surveillance sans mot de passe, Shodan est infiniment plus puissant.

Mon approche actuelle :

• Google : pour les fichiers classiques et les pages web mal configurées.
• Bing : pour les recherches croisées et les types de fichiers que Google a tendance à ignorer.
• Shodan : pour l'analyse des services exposés sur les ports réseau.
• L'indexation directe du site : je vérifie régulièrement `robots.txt` et `sitemap.xml` de mes clients pour comprendre ce qui est censé être public.

Et pour les startups qui veulent du "tout-en-un", des outils open source comme GoogDork ou DorkScan permettent d'automatiser les recherches. J'ai testé les deux. Le premier est plus simple, le second plus puissant, mais aucun ne remplace une compréhension fine des opérateurs.

Spoiler : l'automatisation brute, sans réfléchir aux requêtes, produit des résultats médiocres et vous fait bannir rapidement par Google.

Le cadre légal, cette zone grise qu'on ignore trop souvent

On ne va pas se mentir : la frontière est floue, et elle dépend beaucoup de l'intention.

En France, l'article 323-1 du code pénal est le texte de référence. Il punit "le fait d'accéder ou de se maintenir, frauduleusement, dans tout ou partie d'un système de traitement automatisé de données". La peine peut aller jusqu'à deux ans d'emprisonnement et 100 000 € d'amende.

La question est : qu'est-ce qu'un "accès frauduleux" quand on utilise Google ?

Consulter une page publique indexée par Google n'est pas, en soi, un accès frauduleux. C'est de l'information publique. Mais si la requête a pour but de découvrir des failles pour les exploiter, et que vous franchissez le pas d'aller au-delà de ce que Google vous montre (par exemple, en testant des identifiants trouvés dans un fichier), vous entrez dans une zone beaucoup plus dangereuse.

Un principe que j'applique systématiquement, et que je conseille à tous les auditeurs :

> Ce que Google indexe est public. Ce que vous faites avec cette information est votre responsabilité.

Chercher un fichier `filetype:env` sur votre propre domaine, ou celui d'un client qui a signé un mandat d'audit, est légitime. Chercher le même fichier sur le domaine d'un concurrent, sans autorisation, est au mieux une faute professionnelle, au pire un délit.

Si vous êtes un professionnel de la sécurité, vous le savez déjà. Si vous êtes un curieux qui souhaite apprendre, restez sur votre propre terrain de jeu. Il y a suffisamment de choses à découvrir sur vos propres systèmes pour ne pas avoir à regarder chez les autres.

Comment se former sans mettre les pieds dans le plat

La meilleure façon d'apprendre le dorking sans prendre de risques.

C'est l'angle que je trouve le plus souvent ignoré. Les gens cherchent des listes de dorks, des PDF à télécharger, des "commandes" toutes faites. Mais ils ne construisent pas leur propre environnement de test.

Mon conseil :

1. Créez un serveur de test avec un vieux Raspberry Pi ou une machine virtuelle (VirtualBox, gratuit, fait largement l'affaire).
2. Installez un serveur web (Apache ou Nginx) avec volontairement des fichiers mal configurés : une sauvegarde `.bak`, un fichier `.env` avec de fausses valeurs, un dossier sans index.
3. Publiez le site sur Internet (même sous un domaine de test gratuit) et laissez Google l'indexer. Ça peut prendre quelques jours.
4. Auditez-le avec vos propres dorks jusqu'à retrouver les fichiers que vous avez placés.
5. Corrigez les erreurs de configuration, et recommencez.

Ce cycle d'apprentissage est infiniment plus efficace que lire des listes de requêtes toutes faites. Il vous force à comprendre pourquoi une requête fonctionne, pas seulement ce qu'elle fait.

Et quand vous maîtriserez cette boucle, vous pourrez appliquer la même méthode à des systèmes dont vous avez la responsabilité.

L'avenir du dorking : entre durcissement et spécialisation

Il faut être honnête : la tendance de fond est au durcissement.

Google rend l'automatisation plus difficile. Les serveurs web modernes désactivent l'affichage des répertoires par défaut. Les plateformes de déploiement comme Netlify ou Vercel exposent rarement des fichiers `.env` par erreur. Les équipes de développement sont plus sensibilisées.

Mais il reste des angles morts.

Les sauvegardes restent le maillon faible. On les oublie, on les copie sur un serveur de fichiers ouvert, on les laisse dans un dossier web par commodité. C'est là que le dorking continue de faire des ravages, et c'est là qu'il faut concentrer ses efforts de défense.

Les micro-services et les APIs sont une autre piste. Les développeurs documentent leurs endpoints, publient des exemples de requêtes, et oublient parfois que ces exemples contiennent de vraies clés de test.

Enfin, les moteurs spécialisés comme Shodan ou Censys vont probablement gagner en importance. Le dorking "classique" via Google ne va pas disparaître, mais il va devenir un outil parmi d'autres.

Le Google Dorking se meurt... ou plutôt, il mute. Les opérateurs de recherche ne sont plus un secret. Ce qui reste précieux, c'est la capacité à les combiner intelligemment, à comprendre ce que révèle une configuration serveur, et à savoir ce qu'on cherche avant même de commencer.

Et c'est peut-être la vraie compétence : savoir poser les bonnes questions, même à un vieux moteur de recherche qui a décidé de faire le difficile.