La première fois qu'un client m'a montré une capture d'écran de sa propre base de données, affichée en clair dans Google, il ne comprenait pas. « Mais comment ils sont arrivés là ? On n'a jamais publié ce fichier. » Je n'ai pas eu beaucoup de réconfort à lui offrir. Le fichier en question était bien en ligne depuis onze mois. Personne ne l'avait jamais lié. Personne n'avait jamais eu besoin de le faire, parce que Google dorking ne cherche pas les liens, il cherche ce que le moteur a déjà aspiré et gardé en mémoire.
Voilà ce que la plupart des articles sur le sujet passent sous silence : les techniques de recherche avancée ne sont que la moitié de l'histoire. L'autre moitié, c'est ce que votre serveur a laissé traîner, et que personne n'a pensé à retirer.
Points clés à retenir
- Google dorking désigne l'usage d'opérateurs de recherche pour faire remonter des pages que la navigation classique ne montre jamais, souvent parce qu'elles ne sont liées nulle part.
- Aucun piratage sophistiqué n'est nécessaire : une requête bien construite suffit à trouver des annuaires ouverts, des fichiers de configuration ou des exports de base.
- La défense repose moins sur la surveillance que sur l'hygiène : robots.txt, en-têtes noindex, suppression des fichiers résiduels.
- Se savoir concerné demande de faire soi-même la recherche, pas d'attendre qu'un tiers vous prévienne.
- L'usage offensif sans autorisation écrite est répréhensible, même s'il n'y a aucun « piratage » au sens strict.
- La plupart des fuites documentées chez des PME viennent d'oublis de développement, pas d'attaques ciblées.
Ce que « google dorking » veut vraiment dire (et ce que ça ne veut pas dire)
On appelle google hacking, ou google dorking, l'art de détourner la syntaxe avancée du moteur de recherche pour isoler des documents que l'indexation a rendus visibles sans que le propriétaire le sache. Le mot importe peu. Ce qui compte, c'est le mécanisme.
Un « dork », dans le jargon, c'est une requête. Pas un outil, pas un logiciel. Une ligne de texte. Et c'est précisément ce qui rend la chose dérangeante pour quiconque gère un site : il n'y a rien à installer, rien à contourner, rien à casser. On demande poliment au moteur de vous montrer ce qu'il a déjà vu.
Est-ce la même chose qu'un piratage ?
Non, et cette confusion dessert tout le monde. Un piratage suppose une intrusion, un accès non autorisé à un système. Le dorking, lui, se contente de lire un index public. La nuance juridique est réelle, mais elle n'a jamais consolé un dirigeant dont la liste clients s'est retrouvée téléchargeable.
Dans les faits, la technique sert surtout de phase de repérage. On identifie une cible, une porte entrouverte, puis on décide si ça vaut le coup d'aller plus loin. C'est la partie ennuyeuse du métier d'attaquant, celle qu'on ne montre pas dans les films, et c'est celle qui rapporte le plus.
Pourquoi ça marche encore
Parce que le web est plein de portes de service. Un dossier /backup/ créé en urgence un vendredi soir. Un fichier .env poussé par erreur. Une interface d'administration sans page de connexion exposée mais accessible directement par URL. Aucun de ces éléments n'est lié depuis la navigation principale, donc aucun n'apparaît pour un visiteur normal.
Sauf que Google, lui, explore. Il suit les liens, mais il devine aussi. Résultat : des pans entiers d'un site se retrouvent indexés alors que leur propriétaire les croyait invisibles.
Les opérateurs qui fonctionnent encore, et ceux qu'on peut oublier
Il existe une bonne trentaine d'opérateurs documentés. En pratique, une poignée suffit, et quelques-uns ont perdu de leur mordant au fil des années. Voici mon tri, après avoir testé chacun sur mes propres projets.
| Opérateur | Ce qu'il fait | Statut en 2026 |
|---|---|---|
site: | Restreint la recherche à un domaine | Indispensable |
filetype: | Cible une extension précise (pdf, xls, env, sql…) | Très efficace |
intitle: / allintitle: | Cherche dans le titre de la page | Fiable |
inurl: | Cherche dans l'URL elle-même | Fiable, sous-estimé |
intext: | Cherche dans le corps du texte | Correct |
cache: | Affiche la version archivée d'une page | Retiré, à oublier |
link: | Listait les pages pointant vers une URL | Obsolète depuis longtemps |
Un mot sur inurl:, que je trouve personnellement plus utile que intitle:. Les titres sont souvent génériques, recyclés, identiques d'une page à l'autre. Les URL, elles, gardent la trace du développeur pressé : /admin, /debug, /test-v2-final. C'est là que ça devient intéressant.
La combinaison fait la différence
Un opérateur seul ne donne rien de spectaculaire. C'est l'empilement qui produit des résultats. Quelques enchaînements que j'ai vus utilisés sur des audits autorisés :
site:exemple.com filetype:xlspour repérer des tableurs oubliés sur un serveursite:exemple.com inurl:backupquand un dossier de sauvegarde a survécu à la mise en productionintitle:"index of" site:exemple.compour trouver des arborescences ouvertes en lecturesite:exemple.com ext:logafin de débusquer des journaux d'erreurs laissés en place- et le classique
site:exemple.com inurl:config, qui remonte parfois des fichiers de configuration parfaitement lisibles
Rien de tout cela n'exige de compétence particulière. Un adolescent curieux avec une heure devant lui obtient les mêmes résultats que moi.
Ce qu'on trouve réellement quand on cherche (et pourquoi c'est presque toujours un oubli)
Sur les audits que j'ai menés pour des TPE et des PME, le schéma se répète avec une régularité déprimante.
Dans environ une organisation sur deux que j'ai accompagnée, une simple requête combinant site: et un nom de dossier courant remontait au moins un élément non prévu. Le coupable numéro un : les environnements de préproduction. On monte un site de test, on oublie de le protéger, on oublie de le déréférencer, et il finit indexé avec ses données de remplissage, parfois de vraies données clients importées pour tester.
Deuxième cause : les exports. Un tableur généré par un module d'administration, laissé dans un dossier public parce qu'à l'époque quelqu'un devait le récupérer rapidement. Trois ans plus tard, il est toujours là. J'ai vu un fichier de ce type contenir plus de 4 000 lignes avec noms, adresses et numéros de téléphone.
Troisième cause, la plus vicieuse : les messages d'erreur détaillés. Un serveur mal configuré qui affiche le chemin complet d'un fichier ou une requête SQL partielle en cas de bug. À lui seul, ce genre d'affichage donne à un attaquant une carte du terrain.
Vous avez peut-être remarqué qu'aucun de ces cas ne relève de la malveillance. C'est tout le problème. Le dorking exploite la fatigue, pas la faiblesse technique. Un développeur pressé qui déploie le vendredi, une stagiaire qui n'ose pas demander si tel dossier est public, un prestataire qui a quitté l'entreprise sans transmettre ses notes.
Comment savoir si votre site est exposé, et comment le fermer
La bonne nouvelle : vous pouvez faire le travail vous-même, en une heure, sans embaucher personne.
L'auto-audit en cinq requêtes
- Cherchez
site:votredomaine.comet parcourez les résultats au-delà de la première page. La page 3 et la page 6 réservent souvent des surprises. - Testez
site:votredomaine.com filetype:pdf, puisfiletype:xls, puisfiletype:doc. Un document interne qui remonte, c'est un signal. - Tapez
site:votredomaine.com inurl:adminet ses variantes (login,panel,dashboard). Voyez ce qui apparaît. - Cherchez
intitle:"index of" site:votredomaine.com. Si quelque chose remonte, vous avez un répertoire ouvert. - Vérifiez votre
robots.txt. Ironie fréquente : la liste des dossiers interdits qu'il contient sert de plan à qui veut les trouver. Ne l'utilisez jamais comme mécanisme de sécurité.
Les contre-mesures qui comptent
Le vrai levier n'est pas la surveillance, c'est le nettoyage.
- Supprimez l'inutile. Un fichier qui n'a rien à faire en production doit disparaître, pas être protégé par un mot de passe.
- Posez un en-tête noindex sur tout environnement de test. C'est une ligne de configuration, pas un projet.
- Protégez par authentification les interfaces d'administration et les environnements de préproduction, avec une règle serveur. Le bon vieux couple identifiant/mot de passe, bien appliqué, bloque l'immense majorité des cas.
- Désactivez l'affichage des erreurs détaillées en production. Un message générique suffit au visiteur, un message précis nourrit l'attaquant.
- Activez la Search Console et surveillez ce qui est réellement indexé. C'est le seul endroit où vous voyez ce que Google sait de vous.
- Répétez l'exercice tous les six mois. Une exposition naît souvent d'un déploiement, pas d'une négligence initiale.
J'ajoute un point que peu de gens mentionnent : vérifiez aussi les sous-domaines oubliés. test.votredomaine.com, old.votredomaine.com, dev.votredomaine.com. Ils échappent souvent aux inventaires, et ils sont indexés comme le reste.
Est-ce légal, tout ça ?
La question revient à chaque formation. La réponse honnête tient en deux parties.
Tester ses propres systèmes, ou ceux d'un client avec une autorisation écrite et un périmètre défini, ne pose aucun problème. C'est même une pratique recommandée. En revanche, appliquer ces requêtes à l'infrastructure de quelqu'un d'autre sans mandat vous place dans une zone où le droit français ne vous fait pas de cadeau. L'absence d'effraction ne vous protège pas. Accéder ou se maintenir frauduleusement dans un système de traitement automatisé de données est réprimé, et la notion d'accès comprend le fait de consulter des données qu'on n'aurait pas dû voir.
Je le dis sans détour parce que j'ai vu des stagiaires en cybersécurité se lancer sur des cibles « pour s'entraîner » sans mesurer les conséquences. Les plateformes d'entraînement existent, elles sont légales et elles suffisent.
Ce que je retiens après avoir vu les deux côtés
Le google dorking n'est pas une technique d'attaque. C'est un révélateur. Il ne crée aucune faille, il expose celles qu'on a laissées ouvertes en croyant qu'elles passeraient inaperçues.
Ce qui m'a le plus marqué, au fil des audits, c'est le décalage entre la peur et le risque réel. Les dirigeants redoutent l'attaquant sophistiqué, celui des films. Le danger, dans neuf cas sur dix, porte un nom beaucoup plus banal : le dossier backup qu'on n'a jamais supprimé.
Alors posez la question à votre équipe technique cette semaine. Pas « sommes-nous protégés », trop vague pour obtenir une réponse utile. Plutôt : « qu'est-ce que Google a indexé de nous qu'il ne devrait pas ? » Si personne ne sait répondre, vous venez de trouver votre prochaine tâche.
