Google Dorks : reconnaissance passive et protection

Les Google Dorks sont des requêtes de recherche avancée qui exploitent les opérateurs de Google pour retrouver des informations précises, parfois exposées par erreur : fichiers de configuration, sauvegardes, pages d'administration. C'est la forme la plus accessible de reconnaissance passive : aucune connexion au serveur cible, seulement l'index public de Google. Ce guide s'adresse aux administrateurs et auditeurs qui veulent comprendre ces requêtes, les utiliser pour un audit légitime, et surtout protéger leurs propres sites des fuites qu'elles révèlent.

Ce que vous allez apprendre

Maîtriser les principaux opérateurs de recherche avancée.
Reconnaître les requêtes qui exposent des données sensibles.
Consulter la Google Hacking Database.
Protéger un site contre l'indexation involontaire.
Rester dans un cadre légal et éthique.

Qu'est-ce qu'un Google Dork

Le terme a été popularisé en 2002 par Johnny Long, chercheur en sécurité, qui a montré que des requêtes bien construites révélaient des informations sensibles indexées par erreur. Un Google Dork n'exploite aucune faille du moteur : il affine simplement la recherche avec des opérateurs pour isoler ce qui n'aurait jamais dû être public. C'est pourquoi il figure dans la phase de reconnaissance d'une attaque, au même titre que le scan de ports.

Les opérateurs de recherche

La puissance des Google Dorks tient à une poignée d'opérateurs que l'on combine. Chacun restreint la recherche sur une facette précise de la page.

Opérateur	Rôle	Exemple
`site:`	Limiter à un domaine	`site:exemple.com "confidentiel"`
`filetype:` / `ext:`	Restreindre à un format	`filetype:pdf guide utilisateur`
`intitle:` / `allintitle:`	Chercher dans le titre	`intitle:"rapport annuel"`
`inurl:` / `allinurl:`	Chercher dans l'URL	`inurl:admin`
`intext:` / `allintext:`	Chercher dans le corps	`intext:"mot de passe"`
`cache:`	Version en cache Google	`cache:exemple.com`
`after:` / `before:`	Filtrer par date	`site:exemple.com after:2022-01-01`

Combinés, ces opérateurs deviennent redoutables : filetype:xls site:exemple.com cherche des tableurs sur un domaine précis, et inurl:login intitle:"admin" isole les portails d'administration.

Exemples d'audit

Ces requêtes illustrent ce qu'un audit défensif cherche sur votre propre périmètre. L'objectif est de trouver l'exposition avant un attaquant, jamais de fouiller un tiers sans autorisation.

filetype:xls site:exemple.com
inurl:login intitle:"admin"
intitle:"index of" "parent directory"
filetype:txt "password"
intitle:"error log" filetype:log

Ces motifs cherchent respectivement des tableurs exposés, des pages de connexion, des répertoires ouverts (listing d'index Apache/Nginx mal configuré), des fichiers de mots de passe et des journaux d'erreur laissés accessibles. Une même logique permet de repérer des flux de caméras IP non protégés ou des sauvegardes .sql et .bak indexées.

La Google Hacking Database

La Google Hacking Database (GHDB), hébergée par Exploit-DB, recense des milliers de dorks classés par catégorie : fichiers contenant des mots de passe, pages de connexion, appareils en ligne, messages d'erreur révélateurs. Maintenue par la communauté, elle est un catalogue prêt à l'emploi aussi bien pour l'auditeur que pour l'attaquant. La consulter sur votre propre domaine est un excellent point de départ d'audit.

Protéger votre site

La bonne nouvelle : se prémunir des Google Dorks relève d'une hygiène de configuration classique. Voici les mesures qui coupent l'exposition à la racine.

Sortir les fichiers sensibles de la racine web : config.php, .env, sauvegardes .sql/.bak ne doivent jamais être servis par le serveur web.
Désactiver le listing de répertoires (Options -Indexes sur Apache, autoindex off sur Nginx) pour supprimer les pages « index of ».
Protéger les répertoires d'administration par mot de passe (.htaccess/.htpasswd) ou par filtrage d'IP.
Encadrer l'indexation avec robots.txt, en gardant à l'esprit qu'il cache la page des résultats, pas le fichier : c'est un signal pour les robots honnêtes, pas un contrôle d'accès.
Auditer régulièrement votre domaine avec les dorks eux-mêmes pour détecter ce qui a fuité.

User-agent: *
Disallow: /admin/
Disallow: /confidential/

Cadre légal et éthique

Le fait qu'une donnée soit techniquement accessible ne la rend pas libre d'exploitation. Consulter des informations personnelles indexées par erreur peut constituer une atteinte à la vie privée ou une infraction, selon les lois locales. Trois principes encadrent tout usage :

Autorisation préalable : sur un périmètre tiers, un audit ne se mène que dans le cadre d'un contrat de test d'intrusion explicite.
Ne pas exploiter les données trouvées : les repérer pour alerter le propriétaire est légitime, s'en servir ne l'est pas.
Distinguer audit et intrusion : vérifier la présence de fichiers publics est acceptable ; contourner un mécanisme de sécurité ne l'est jamais.

Outils qui automatisent les dorks

Plusieurs outils enchaînent des dorks à grande échelle pour un audit systématique. Ils montrent aussi la facilité avec laquelle un attaquant collecte des données exposées.

SiteDorks : lance une batterie de dorks contre un domaine précis.
GooDork : outil en ligne de commande Python pour scripter les recherches.
theHarvester : collecte e-mails et sous-domaines, avec un volet dorking, utile en début d'audit.

À retenir

Un Google Dork est une requête avec opérateurs qui isole des données précises dans l'index public de Google.
Il n'exploite aucune faille : il révèle une mauvaise configuration qui a laissé un fichier crawlable.
Les opérateurs clés sont site:, filetype:, intitle:, inurl: et intext:.
La protection est une hygiène de configuration : sortir les fichiers sensibles de la racine, couper le listing, authentifier l'administration.
robots.txt n'est pas un contrôle d'accès : il faut de l'authentification ou du retrait, pas du camouflage.
Sur un périmètre tiers, l'usage exige une autorisation écrite.

FAQ : questions fréquentes

Qu'est-ce qu'un Google Dork ?

Un Google Dork est une requête de recherche avancée qui utilise des opérateurs comme site:, filetype: ou intitle: pour isoler des informations précises dans l'index public de Google, souvent des données exposées par erreur. Il n'exploite aucune faille du moteur.

Utiliser des Google Dorks est-il légal ?

Consulter des résultats publics est légal, mais exploiter des données personnelles indexées par erreur peut constituer une atteinte à la vie privée selon les lois locales. Un audit sur un périmètre tiers exige une autorisation écrite, comme un contrat de test d'intrusion.

Comment protéger son site des Google Dorks ?

Sortez les fichiers sensibles (config, .env, sauvegardes) de la racine web, désactivez le listing de répertoires, protégez l'administration par authentification, et auditez votre domaine avec des dorks. robots.txt ne suffit pas : il cache la page des résultats, pas le fichier.

Qu'est-ce que la Google Hacking Database (GHDB) ?

La Google Hacking Database, hébergée par Exploit-DB, est un catalogue communautaire de milliers de Google Dorks classés par catégorie : fichiers de mots de passe, pages de connexion, appareils en ligne, messages d'erreur. Elle sert aussi bien à l'audit défensif qu'à l'attaque.

Prochaines étapes

Nmap : scan de ports et de services La reconnaissance active qui complète le dorking passif.

Banner grabbing Identifier les services exposés et leurs versions.

La phase de reconnaissance Où se situe le dorking dans le déroulé d'une attaque.