Bon. Parlons franchement du Google Dorking. Vous avez probablement vu passer ce terme dans un article de cybersécurité, peut-être même dans un film où un hacker tape trois lignes et accède à des fichiers top secret. Mais la réalité est plus subtile — et plus inquiétante.
J'utilise ces techniques depuis des années. Pas pour pirater, mais pour comprendre comment les moteurs de recherche exposent nos données. Et croyez-moi : ce que Google indexe sans que personne le remarque est parfois terrifiant.
Points clés à retenir
- Le Google Dorking consiste à utiliser des opérateurs de recherche avancée pour trouver des données sensibles indexées par erreur.
- Ces requêtes sont légales à formuler, mais leur usage peut devenir illégal selon l'intention et l'exploitation des résultats.
- Les opérateurs essentiels :
site:,inurl:,filetype:,intitle:— et leurs combinaisons. - Les fichiers exposés les plus courants sont les fichiers de configuration, les exports de bases de données et les sauvegardes.
- La protection repose sur des robots.txt corrects, la dé-indexation et une hygiène de publication rigoureuse.
Le Google Dorking, c'est quoi exactement ?
Google indexe le web en suivant les liens. Mais il indexe tout ce qu'il trouve : y compris les fichiers que vous avez oubliés sur un serveur, les pages de test, les exports de bases de données laissés traîner. Le dorking, c'est l'art de poser les bonnes questions à Google pour tomber sur ces fichiers.
Un exemple ? La requête suivante :
filetype:sql inurl:backup
Cette simple ligne cherche les fichiers SQL nommés "backup" accessibles publiquement. J'ai testé cette recherche sur de petits sites d'associations locales. Sur une trentaine de domaines, j'ai trouvé deux exports de bases de données contenant des adresses email et des numéros de téléphone. Deux. Sans aucun outil de hacking. Juste Google.
C'est pour cela que les pentesters adorent le dorking : c'est la première étape de reconnaissance. Rapide, discrète, et diablement efficace.
L'opérateur site: — votre ami et votre pire ennemi
L'opérateur le plus simple est aussi le plus puissant. La syntaxe est enfantine : `site:votresite.fr`. Mais c'est ce qu'on ajoute après qui change tout.
Quand je forme des équipes techniques, je leur montre cette séquence :
- `site:monsite.fr filetype:env` — pour trouver les fichiers de configuration d'environnement (souvent avec des mots de passe en clair)
- `site:monsite.fr filetype:log` — les journaux de serveur, qui traînent parfois des sessions actives
- `site:monsite.fr inurl:admin` — les panneaux d'administration non protégés par mot de passe
J'ai vu une entreprise de taille moyenne exposer son fichier `.env` contenant les identifiants de sa base de production. La requête était triviale, le résultat — catastrophique.
Les opérateurs Google, une liste pratique et leurs limites
Avant de vous donner ma liste de dorks favorites, parlons des opérateurs eux-mêmes. En voici la liste, avec ce qu'ils font vraiment.
| Opérateur | Fonction | Usage efficace |
|---|---|---|
| `site:` | Restreint à un domaine | `site:exemple.fr filetype:pdf` |
| `inurl:` | Cherche dans l'URL | `inurl:phpmyadmin` |
| `intitle:` | Cherche dans le titre de la page | `intitle:"index of"` |
| `filetype:` | Filtre par type de fichier | `filetype:xlsx password` |
| `intext:` | Cherche dans le texte de la page | `intext:"confidential"` |
| `cache:` | Affiche la version en cache de Google | `cache:exemple.fr` |
| `link:` | Recherche les pages qui pointent vers une URL | `link:exemple.fr` |
Un point important : tous ces opérateurs se combinent. `intitle:"index of"` est l'un des plus connus, car il trouve les listages de répertoires de serveurs Apache mal configurés. Ajoutez `"parent directory"` et vous obtenez des résultats encore plus précis.
Le piège ? Google a supprimé ou affaibli certains opérateurs au fil des années. `link:` ne fonctionne plus comme avant, `cache:` est de plus en plus capricieux. La liste ci-dessus reste valable en 2026, mais il faut vérifier régulièrement.
Pourquoi j'utilise Google Dorks pour la reconnaissance en pentest
Dans un audit de sécurité, la première phase est la reconnaissance passive : collecter des informations sans toucher à la cible. Le dorking s'inscrit parfaitement ici.
Voici une série de dorks que j'ai utilisée lors d'un audit pour une PME du secteur financier :
site:ma-cible.fr filetype:pdf "confidentiel"
site:ma-cible.fr intitle:"index of" /backup
site:ma-cible.fr filetype:log
Résultat : un fichier PDF confidentiel non protégé, un répertoire de sauvegarde listé publiquement, et un fichier de log vieux de trois ans. Pour l'audit, c'était une mine d'or. Pour la sécurité de l'entreprise, une catastrophe évitée de justesse.
Avouons-le : la première fois que j'ai vu ce répertoire de sauvegarde, j'ai failli laisser tomber mon café. Le nom du fichier était littéralement `backup_2023_mysql.sql.gz`. Pas d'effort pour le cacher. Rien.
Les contre-mesures : comment empêcher le dorking sur votre site
Si vous êtes responsable d'un site web, vous pouvez faire plusieurs choses pour éviter d'apparaître dans ces résultats. La première : un fichier `robots.txt` correctement configuré.
Voici un exemple de base :
User-agent: *
Disallow: /backup/
Disallow: /admin/
Disallow: /*.sql
Disallow: /*.env
Ça n'est pas parfait — les robots.txt ne sont qu'une recommandation, pas une obligation — mais Google les respecte généralement. Pour les fichiers déjà indexés, il existe un autre outil : la « suppression d'URL » dans Google Search Console.
Quand j'ai réalisé que même les robots.txt ne suffisent pas
J'ai découvert la faille des robots.txt de la manière la plus embarrassante qui soit. Sur mon propre blog, j'avais mis des fichiers de test dans un dossier `/temp/`. Le robots.txt les bloquait. Pourtant, une recherche `site:monsite.fr filetype:txt` les faisait apparaître.
Pourquoi ? Parce que Google avait indexé ces fichiers avant que j'ajoute la directive. Les robots.txt ne s'appliquent pas rétroactivement. J'ai dû utiliser l'outil de suppression de Google, puis ajouter une balise `
` dans le dossier.Depuis ce jour, je vérifie systématiquement ce qui est indexé avec une simple recherche `site:monsite.fr` avant de supposer que mes protections fonctionnent.
La question de la légalité : où est la ligne rouge ?
C'est le sujet que tout le monde évite. Le dorking n'est pas illégal en soi — taper une requête dans Google ne pose pas de problème. L'illégalité commence quand vous utilisez les résultats.
Accéder à une base de données SQL exposée ? Si vous vous contentez de la voir, la loi est floue. Si vous la téléchargez ou l'utilisez, c'est une intrusion. Pire : si l'entreprise porte plainte, la simple consultation peut être requalifiée en accès frauduleux selon la jurisprudence.
Mon conseil est simple : ne dépassez jamais la lecture superficielle. Dans mes audits, tout est documenté, horodaté, et autorisé par un contrat signé. Sans mandat, je m'arrête à la constatation de l'exposition, puis je préviens l'entreprise concernée.
Le Google Dorking face aux autres moteurs : une nouvelle donne
Google n'est plus le seul terrain de jeu. Depuis quelques années, j'utilise aussi Shodan — le moteur de recherche des appareils connectés — et Bing pour croiser les résultats.
Shodan ne cherche pas dans les pages web, mais dans les IP et les ports ouverts. La complémentarité est évidente : Google trouve le fichier exposé, Shodan révèle l'infrastructure qui le sert. Pour un audit sérieux, les deux sont nécessaires.
Et Bing ? Son index est moins complet que celui de Google, mais il a un avantage : il respecte moins scrupuleusement les robots.txt. Un fichier que Google a retiré peut encore apparaître dans les résultats de Bing pendant des semaines. Une bonne raison de vérifier les deux quand vous dé-indexez un fichier sensible.
Erreurs courantes que je vois dans les entreprises
J'ai accompagné plusieurs équipes techniques sur ces sujets. Voici les trois erreurs que je rencontre à chaque fois :
- La fausse sécurité des robots.txt : bloquer une URL à Google ne la rend pas inaccessible aux autres moteurs, ni aux visiteurs directs qui connaissent le lien.
- L'oubli des fichiers de sauvegarde : les sauvegardes locales sont souvent correctement protégées, mais les sauvegardes cloud sont parfois publiques par défaut.
- L'absence de vigilance sur les fichiers de test : les fichiers de test (`test.sql`, `debug.log`, `config.php.bak`) sont un terrain de jeu idéal pour les dorks, car ils portent des noms prédictibles.
Mon anecdote préférée reste cette entreprise qui avait laissé un fichier `phpinfo.php` sur un serveur de production. Pour ceux qui ne connaissent pas : ce fichier affiche la configuration complète du serveur PHP. La requête `filetype:php intext:"phpinfo()"` le trouve en quelques secondes. L'entreprise avait des données clients dans la même base que ce serveur. Une seule page, et tout tombait en morceaux.
Comment se former au dorking sans faire de bêtises
Si vous voulez apprendre sérieusement, la méthode est simple : utilisez des terrains d'entraînement. Des plateformes comme Hack The Box ou TryHackMe proposent des machines virtuelles où l'objectif est précisément d'utiliser le dorking pour trouver des fichiers cachés. Légal, sécurisé, et formateur.
Commencez par des requêtes inoffensives sur votre propre domaine. Regardez ce que Google indexe de vous. Cherchez vos propres fichiers exposés. C'est étonnamment révélateur.
Ensuite, passez aux outils qui automatisent le processus. Des outils comme GHDB (Google Hacking Database) recensent les dorks les plus efficaces. Vous pouvez aussi écrire vos propres scripts pour automatiser les recherches, mais attention : une utilisation automatisée à grande échelle peut être considérée comme une attaque par les forces de l'ordre.
Pourquoi cette pratique est devenue incontournable en cybersécurité
Le Google Dorking n'est plus une astuce de bidouilleur. C'est devenu un réflexe de base pour tout professionnel de la sécurité.
Quand j'évalue la sécurité d'une entreprise, la question n'est plus « est-ce que vos données sont exposées ? » mais « combien de vos données sont exposées sur Google ? ». La réponse est souvent plus longue que ce que les équipes imagineraient.
Et voici la partie la plus troublante : la plupart de ces expositions ne sont pas le fait de hackers. Ce sont des erreurs humaines. Un fichier uploadé au mauvais endroit. Un paramètre de visibilité mal réglé. Une sauvegarde laissée sur le serveur après une migration. Rien d'exotique. Juste des erreurs banales qui deviennent des vulnérabilités par la simple existence d'outils de recherche puissants.
Alors, la prochaine fois que quelqu'un vous dira que Google ne voit que les pages publiques, posez-lui une question simple : « Voyez-vous les fichiers que vous avez oubliés ? »
