Google dorking : la méthode secrète des pros du web

Un client m'appelle un mardi matin, paniqué. Il vient de découvrir que ses tarifs fournisseurs 2026 étaient accessibles en clair, rangés dans un dossier Excel, sur un sous-domaine oublié de son propre site. Personne ne l'avait piraté. Personne n'avait forcé une porte. La porte était ouverte, avec une étiquette dessus, et il suffisait de taper trois mots dans la barre de recherche de Google pour la trouver.

Cette technique porte un nom : le google dorking. Aussi appelé google hacking. Et si vous gérez un site, un serveur, une boutique en ligne ou même un compte pro, vous avez tout intérêt à comprendre comment vos concurrents, et surtout les curieux mal intentionnés, s'en servent. Parce que ce que Google indexe sans le savoir, n'importe qui peut le lire.

Google dorking : comment trois mots dans une barre de recherche exposent vos données

Le principe tient en une phrase. Google indexe tout ce qu'il peut atteindre. Y compris ce qui ne devait jamais être public. Une sauvegarde de base de données laissée dans un coin, un PDF interne, un panneau d'administration sans mot de passe. Le moteur ne sait pas faire la différence entre un document destiné aux clients et un document destiné à trois personnes dans l'entreprise. Il voit du contenu, il le range.

Le dorking, c'est l'art de demander à Google exactement ce qu'on cherche, en utilisant sa syntaxe avancée plutôt que les mots du langage courant. Au lieu de taper « tarifs grossiste », vous tapez une requête qui dit : montre-moi tous les fichiers Excel contenant ce mot, sur des sites en France, dont l'URL ressemble à un espace privé.

Pourquoi ça marche aussi bien

Trois raisons, et aucune n'est un bug de Google.

La première, c'est l'indexation automatique. Un développeur déploie un dossier de test le vendredi, il oublie de le supprimer lundi. Google le trouve, l'indexe, et personne ne s'en aperçoit avant des mois.

La deuxième, c'est la croyance naïve dans le robots.txt. Beaucoup d'équipes pensent que ce fichier cache leur contenu. Faux. Il dit « merci de ne pas entrer », il n'empêche rien. Un crawler qui l'ignore passe outre, et un être humain qui connaît l'URL ouvre la page directement.

La troisième tient à la nature même des opérateurs. Ils sont documentés publiquement, par Google lui-même, et n'importe quel débutant peut les apprendre en une soirée. Je l'ai fait. J'avais vingt ans, aucune notion de sécurité, et au bout de deux heures je trouvais des annuaires d'entreprise mal configurés sur des domaines réels. Cette nuit-là j'ai compris que le problème n'était pas la technique. Le problème était en face.

Les opérateurs qui font le travail (et ceux qui sont morts)

Tous les tutos se recopient les mêmes listes. Le souci, c'est que Google retire des opérateurs de temps en temps, sans prévenir, et les articles continuent de les citer fièrement. Je me suis fait avoir en préparant une formation l'an dernier : trois des commandes que je voulais montrer à mes stagiaires ne renvoyaient plus rien. Aucun message d'erreur, juste du vide. Il a fallu que je teste une par une pour m'en rendre compte.

Ce qui fonctionne encore

• filetype: — limite la recherche à un format. C'est le plus connu et le plus utile.
• intitle: et allintitle: — impose la présence d'un mot dans le titre de la page. Redoutable pour repérer les panneaux d'administration.
• inurl: — même logique mais sur l'adresse de la page. Utile pour repérer des dossiers ouverts ou des paramètres suspects.
• site: — restreint la recherche à un domaine précis. C'est l'opérateur que j'utilise le plus en audit.
• Les guillemets — pas un opérateur au sens strict, mais le moyen le plus simple de forcer une expression exacte.

Ce qui ne fonctionne plus

Plusieurs opérateurs historiques ont disparu ou changé de comportement au fil des refontes de l'index. info: a longtemps servi à obtenir des informations sur une page : il ne renvoie plus ce qu'il promettait. cache:, qui affichait la version archivée d'une page, a fini par sauter aussi, après des années de dépérissement progressif. Certains opérateurs de proximité, autrefois très souples, sont aujourd'hui traités avec beaucoup plus de rigidité.

La leçon, franchement, est simple : ne faites jamais confiance à une liste figée, y compris la mienne. Testez la commande sur un cas que vous connaissez avant de conclure quoi que ce soit. Si vous cherchez une liste à télécharger en PDF, sachez que les documents qui circulent sont souvent périmés de plusieurs années. Prenez-les comme point de départ, pas comme référence.

Exemples concrets de dorks, et ce qu'ils révèlent

Voici à quoi ressemble une requête utile. Le format est toujours le même : un opérateur, deux points, une valeur.

Objectif	Structure de requête	Ce que ça met au jour
Documents internes	site:exemple.fr filetype:pdf intitle:confidentiel	Notes de service, rapports, contrats mal rangés
Feuilles de calcul exposées	site:exemple.fr filetype:xlsx	Tarifs, listes clients, plannings
Interfaces d'administration	intitle:"index of" inurl:admin	Dossiers ouverts sans page d'accueil
Fichiers de configuration	filetype:env inurl:exemple	Clés d'API, identifiants de base de données

Vous remarquerez qu'aucune de ces requêtes ne contient de mot « pirate ». C'est justement ce qui rend la chose dérangeante. La barre de recherche de Google n'est pas un outil de hacking. Elle fonctionne exactement comme prévu. C'est la configuration en face qui est en défaut.

Le cas des liens d'invitation de groupe

Un détail que l'on m'a montré récemment m'a marqué. Les liens d'invitation à des groupes de messagerie, du type « rejoindre ce groupe via un lien » (je pense à WhatsApp et à ses concurrents), sont parfois indexés par Google alors qu'ils ont fuité sur des forums publics ou dans des pages laissées en accès libre. Un petit malin peut alors tomber sur des groupes privés d'entreprise et lire ce qui s'y raconte. Je n'ai pas testé moi-même, je n'ai aucune envie de me retrouver dans un groupe dont je ne fais pas partie, mais la logique est la même que pour un PDF oublié : une URL partagée quelque part finit par se retrouver dans l'index.

Du coup, la question que tout le monde se pose.

Est-ce légal, en France, de chercher comme ça ?

Distinguons deux choses, et cette distinction est capitale.

Consulter une page accessible au public, même si elle n'aurait pas dû l'être, ne relève pas en soi d'une infraction. Vous n'avez forcé aucun accès, vous n'avez contourné aucun dispositif de protection. Vous avez lu ce que Google vous servait.

Mais dès que vous collectez, stockez, exploitez ou divulguez des données personnelles trouvées de cette façon, vous entrez dans le champ du RGPD et, potentiellement, du code pénal. Accéder à un système de traitement automatisé de données sans autorisation est une infraction, même sans mot de passe cassé, dès lors que l'accès n'était pas prévu pour vous. Et revendre ou publier ces données aggrave encore les choses.

Ma position est claire et je n'en changerai pas : si vous tombez sur une fuite par hasard ou en testant votre propre site, vous documentez et vous signalez. Vous ne fouillez pas plus loin. Le frisson de la découverte n'excuse rien.

Côté défense : ce que je vérifie maintenant systématiquement

Depuis cet appel du mardi matin, je fais un audit d'exposition sur chaque projet que je récupère. Ça me prend environ une heure, et j'ai déjà évité au moins deux incidents à des clients qui n'auraient jamais pensé à vérifier.

La vérification en cinq requêtes

1. Cherchez votre propre domaine avec site: suivi d'un filetype: pour chaque format sensible : pdf, xlsx, docx, env, sql, bak.
2. Testez intitle:"index of" site:votredomaine. Si des dossiers remontent, c'est ouvert.
3. Cherchez vos sous-domaines oubliés. Ce sont les coins où personne ne regarde, et donc les coins où le ménage n'est pas fait.
4. Vérifiez que vos espaces privés renvoient bien une authentification, pas une page blanche ni une erreur 404 sans protection.
5. Refaites le test après chaque mise en production. Oui, à chaque fois. C'est pénible, c'est indispensable.

La vraie protection n'est pas dans Google

Rien de ce que vous mettrez dans robots.txt ne vous sauvera. La protection se joue à trois niveaux, et dans cet ordre : l'authentification sur les zones sensibles, la suppression physique des fichiers qui n'ont rien à faire sur le serveur, et le nettoyage régulier des sous-domaines et dossiers abandonnés. Google ne fait que refléter ce que vous avez exposé. Corrigez la source, pas la vitrine.

Et si vous découvrez une fuite sur le site de quelqu'un d'autre ? Ne diffusez rien. Notez l'URL, la date, ce que vous avez vu. Cherchez une adresse de contact technique ou une politique de divulgation responsable s'il en existe une, sinon écrivez au contact général en restant factuel et bref. La plupart des équipes réagissent bien quand on leur apporte le problème discrètement. Elles paniquent quand elles découvrent qu'un inconnu a publié leur erreur sur un forum.

À quoi ça sert vraiment, une fois qu'on a compris

Le google dorking a deux visages. Pour le curieux, c'est une porte entrouverte sur tout ce que le web n'a pas rangé correctement. Pour le responsable technique, c'est avant tout un outil d'audit gratuit, disponible immédiatement, qui ne demande aucune licence ni aucun scanner payant.

Ce qui me frappe, après toutes ces années, c'est que les failles les plus fréquentes ne sont jamais spectaculaires. Pas de script sophistiqué, pas de vulnérabilité exotique. Un dossier oublié. Une sauvegarde laissée sur le serveur. Un sous-domaine que plus personne ne maintient depuis qu'un stagiaire l'a créé pour une démo. La négligence ordinaire bat les exploits brillants, tous les jours de la semaine.

Alors avant de chercher à sécuriser des choses compliquées, prenez une heure et tapez le nom de votre propre site dans la barre de recherche de Google, suivi de deux points et d'un format de fichier. Vous pourriez être surpris. Et si vous ne l'êtes pas, tant mieux : c'est que quelqu'un, quelque part, a fait son travail. Peut-être même que c'était vous.