Google Dorking : la technique de recherche qui expose vos données sensibles
Vous tapez "mot de passe" dans Google et vous tombez sur des résultats inoffensifs. Moi, je tape une requête précise avec des opérateurs, et je peux trouver des fichiers `.env` contenant des clés API de startups françaises. C'est ça, le Google Dorking.
Avant de crier au piratage, laissez-moi être clair : cette pratique n'est ni illégale en soi, ni un hack sophistiqué. C'est simplement l'art d'utiliser Google comme un scalpel au lieu d'un marteau. Les opérateurs de recherche avancée — `site:`, `filetype:`, `intitle:` — deviennent des armes de reconstitution massive quand on les combine intelligemment.
Points clés à retenir
- Le Google Dorking utilise les opérateurs de recherche avancée pour trouver du contenu non indexé intentionnellement
- C'est un outil à double tranchant : formidable pour la cybersécurité offensive, dangereux entre de mauvaises mains
- Les fichiers les plus exposés sont les configurations, backups, et journaux oubliés
- La protection repose sur robots.txt, les en-têtes HTTP et une hygiène numérique rigoureuse
- Le cadre légal en France repose sur l'article 323-1 du code pénal — même une simple consultation peut être sanctionnée
Exemples concrets de Dorks qui fonctionnent vraiment
J'ai passé des années à tester ces requêtes sur des périmètres autorisés. Voici celles qui m'ont le plus surpris par leur efficacité :
Les fichiers de configuration exposés
filetype:env "DB_PASSWORD" -github.com
Cette requête cherche les fichiers d'environnement contenant des mots-clés de base de données, en excluant GitHub où ils sont souvent volontairement partagés. Le résultat ? Des serveurs de production avec des identifiants en clair. J'ai trouvé une base MongoDB ouverte d'une PME française comme ça. Tout était accessible : noms, emails, numéros de téléphone de leurs clients. La RGPD n'aime pas ça, croyez-moi.
Les données personnelles qui trainent
filetype:xlsx "nom" "prénom" "téléphone" site:gouv.fr
Oui, ça fonctionne. Des fichiers Excel entiers, indexés par Google, contenant des données personnelles de citoyens. La douleur que j'ai ressentie en voyant certains résultats… Je ne peux pas tout raconter ici, mais disons que certaines administrations ont des pratiques de publication pour le moins hasardeuses.
Les serveurs oubliés
intitle:"index of" "backup" "zip" -site:github.com
Les serveurs Apache avec le listing de répertoires activé montrent tout leur contenu. Des backups complets, parfois vieux de plusieurs années, avec des données obsolètes mais sensibles. Une entreprise de e-commerce avait laissé un export complet de sa base clients de 2019. Le fichier était toujours là, indexé, téléchargeable.
La liste des opérateurs essentiels pour le Dorking
Tout commence par la maîtrise des opérateurs de base. En voici la liste que j'utilise quotidiennement :
| Opérateur | Fonction | Exemple | Usage typique |
|---|---|---|---|
| `site:` | Restreint à un domaine | `site:monsite.fr` | Cartographier les pages indexées |
| `intitle:` | Mot dans le titre | `intitle:"index of"` | Trouver les listings de répertoires |
| `inurl:` | Mot dans l'URL | `inurl:admin` | Détecter les interfaces d'administration |
| `filetype:` | Extension de fichier | `filetype:pdf` | Identifier les documents exportés |
| `intext:` | Texte dans la page | `intext:"mot de passe"` | Chercher des mots-clés sensibles |
| `cache:` | Version en cache | `cache:monsite.fr` | Voir une version supprimée |
| `related:` | Sites similaires | `related:monsite.fr` | Trouver des sites concurrents |
| `-` (moins) | Exclusion | `filetype:pdf -site:gouv.fr` | Filtrer les résultats |
Le cadre légal : ce qu'on ne vous dit jamais
Voilà le point que la plupart des tutoriels évitent soigneusement. En France, l'article 323-1 du code pénal sanctionne l'accès frauduleux à un système de traitement automatisé de données. La question qui fâche : est-ce qu'une requête Google qui affiche un fichier sensible constitue un "accès frauduleux" ?
Franchement ? C'est gris. La jurisprudence n'est pas claire à 100 %.
Ce que je sais, c'est que dans mon travail de testeur d'intrusion, j'ai un périmètre écrit, signé, et des règles d'engagement précises. Sans ça, je ne touche à rien. La règle d'or reste : si les données sont indexées par Google, c'est que quelqu'un a fait une erreur. Mais ce n'est pas une invitation à les exploiter.
La consultation d'une page indexée n'est pas en soi illégale. En revanche, télécharger des données personnelles, les utiliser, ou les revendre, ouvre la porte à des poursuites. Le RGPD ajoute une couche supplémentaire : collecter des données personnelles sans base légale, c'est 4% du chiffre d'affaires mondial en amende. Même pour un usage "de curiosité".
Les usages légitimes que personne ne mentionne
Tout le monde parle de sécurité offensive. Personne ne parle de l'utilisation professionnelle classique.
La veille concurrentielle par le Dorking
site:concurrent.fr filetype:pdf "tarif"
J'ai utilisé cette technique pour un client qui voulait connaître les grilles tarifaires de ses concurrents. En dix minutes, j'avais trois documents PDF publics, indexés, que les équipes marketing de nos concurrents avaient oublié de protéger. C'est de la veille légale, basée sur des informations publiques.
La recherche académique et l'open data
Les chercheurs utilisent ces mêmes opérateurs pour trouver des données ouvertes. Les administrations publient des milliers de fichiers, et le Dorking permet de les retrouver sans passer par des portails parfois mal organisés.
site:data.gouv.fr filetype:xlsx
Une manière rapide de lister les jeux de données disponibles, même ceux qui sont mal référencés.
Comment se protéger contre le Google Dorking
J'ai passé des années à auditer des systèmes, et je vois les mêmes erreurs partout. Voici les mesures concrètes que j'applique systématiquement :
Le robots.txt : votre première ligne de défense
User-agent: *
Disallow: /admin
Disallow: /backup
Disallow: /*.env$
Disallow: /*.sql$
Mais attention : ce fichier est un signal, pas une barrière. Il indique aux robots respectueux ce qu'ils doivent ignorer. Un attaquant le lira pour identifier exactement où chercher. Le robots.txt protège des moteurs, pas des humains mal intentionnés.
Les en-têtes HTTP et le noindex
La vraie protection passe par les en-têtes HTTP :
X-Robots-Tag: noindex, nofollow
Appliqué aux répertoires sensibles, cet en-tête dit aux moteurs de ne pas indexer le contenu. Combiné avec une authentification forte sur les zones sensibles, c'est la solution la plus fiable.
L'hygiène numérique de base
La plupart des expositions viennent d'erreurs humaines :
- Ne jamais stocker de fichiers sensibles dans le répertoire public d'un serveur web
- Utiliser des noms de fichiers non devinables
- Vérifier régulièrement ce que Google indexe de votre domaine avec `site:monentreprise.fr`
Pendant un audit, j'ai demandé à un client de faire cette simple recherche. Il a découvert trois fichiers de configuration exposés, dont un avec les identifiants de son serveur de production. Il ne le savait pas. Personne ne le savait. Google, si.
Quand la curiosité devient un problème
La frontière entre exploration et intrusion est mince. Si vous trouvez un fichier sensible, la bonne réaction est simple :
Ne téléchargez rien. Notez ce que vous avez vu. Contactez le propriétaire du site via les canaux de signalement prévus (certains sites ont des programmes de bug bounty). Et surtout, n'en parlez pas publiquement en montrant des captures d'écran. C'est une erreur que j'ai faite au début, et elle m'a valu des ennuis avec un client qui avait mal configuré son serveur.
Le Dorking, c'est comme un passe-partout. L'outil n'est ni bon ni mauvais. Ce qui compte, c'est ce qu'on en fait. Utilisez-le pour comprendre votre exposition, pas pour exploiter celle des autres. Et si vous trouvez quelque chose, signalez-le. La responsabilité, c'est aussi ça, la cybersécurité.
La prochaine fois que vous verrez une requête Google avec des opérateurs étranges, souvenez-vous : quelqu'un cherche peut-être ce que vous avez oublié de protéger. Et la seule façon de le savoir, c'est de chercher avant eux.
