Google dorking : la technique secrète des hackers pour tout trouver sur le web

Google Dorking : la puissance cachée de la recherche Google (et comment vous protéger)

Vous tapez une requête dans Google, vous obtenez des résultats. Simple, non ? Pourtant, il existe une manière de poser des questions à Google qui révèle des choses qu'il n'est pas censé montrer. Des fichiers de mots de passe, des bases de données clients, des caméras de surveillance ouvertes sur le monde, des documents internes d'entreprise. Tout cela est accessible, souvent sans aucune protection, à condition de connaître les bons mots-clés.

Cette pratique, c'est le Google Dorking. J'utilise ces techniques depuis des années, aussi bien pour auditer la sécurité de mes propres projets que pour comprendre à quel point nos données sont exposées. Spoiler : c'est bien pire que ce que vous imaginez. Et la partie la plus dérangeante, c'est que la plupart de ces expositions ne relèvent pas d'un piratage complexe, mais d'une simple négligence.

L'objectif ici n'est pas de vous transformer en hacker, mais de vous montrer comment fonctionne cet outil à double tranchant, pourquoi il est crucial de s'en méfier, et surtout, comment vous pouvez protéger vos propres données et celles de votre entreprise. Avouons-le, c'est un sujet fascinant, mais qui mérite qu'on parle franchement des aspects légaux et éthiques.

C'est quoi, concrètement, une "dork" ?

Une dork, c'est une requête qui utilise des opérateurs spéciaux pour affiner la recherche bien au-delà des mots-clés simples. Ces opérateurs existent officiellement ("filetype:", "site:", "intitle:"), mais leur combinaison permet de créer des requêtes très puissantes.

Par exemple, une requête comme `filetype:pdf "confidentiel"` vous donnera tous les PDF indexés contenant le mot "confidentiel". Rien de bien méchant. Mais si je cherche `filetype:xlsx "mot de passe" site:gouv.fr`, ça devient tout de suite plus intéressant (et plus inquiétant). C'est ce genre de combinaison qui transforme une simple fonctionnalité de recherche en un outil de collecte d'informations redoutable.

J'ai fait un test simple sur un projet personnel il y a quelques mois. Un site vitrine que j'avais oublié, avec un fichier `backup.zip` à la racine. La requête `site:monsite.fr filetype:zip` le trouvait en une seconde. La leçon ? Je n'avais pas pensé à protéger ce fichier, et n'importe qui pouvait le télécharger. Ce jour-là, j'ai compris que le problème n'était pas la technique, mais la négligence.

Voici quelques opérateurs de base à connaître :

• `intitle:` ou `allintitle:` : recherche dans le titre de la page.
• `inurl:` ou `allinurl:` : recherche dans l'URL.
• `filetype:` : recherche un type de fichier précis (pdf, xlsx, sql, log, etc.).
• `site:` : restreint la recherche à un domaine ou un sous-domaine.
• `intext:` : recherche dans le texte de la page.
• `cache:` : affiche la version en cache d'une page.

La force d'une dork réside dans la combinaison de ces opérateurs. Une requête du type `inurl:admin intitle:"index of"` permet de trouver des serveurs Apache avec la liste des fichiers ouverte. C'est une porte d'entrée potentielle pour un attaquant.

Exemples de dorks pour la recherche de données sensibles

Voici quelques exemples classiques que l'on retrouve dans les listes de dorks partagées entre passionnés (et parfois entre pirates). Je vous les montre pour que vous mesuriez le danger, pas pour que vous les testiez sur des cibles qui ne vous appartiennent pas.

• `filetype:sql "INSERT INTO" "password"` : pour trouver des exports de bases de données SQL bruts.
• `intitle:"index of" "backup"` : pour trouver des répertoires ouverts contenant des sauvegardes.
• `filetype:log "password"` : pour dénicher des fichiers journaux qui contiennent des traces d'authentification.
• `inurl:php?file=` : pour repérer des potentielles failles d'inclusion de fichier local (LFI) dans des scripts PHP.
• `"Powered by WordPress" inurl:wp-content` : pour identifier les sites sous WordPress et chercher leurs failles connues (c'est plus un travail de foot-printing, mais ça en fait partie).

J'ai testé la requête sur les fichiers `.env` il y a quelque temps, juste pour voir. `filetype:env "DB_PASSWORD"`. Le nombre de résultats avec des identifiants de bases de données en clair est tout simplement effrayant. Et le pire, c'est que ces fichiers sont souvent à la racine du site, accessibles sans aucune authentification. Sur un audit pour un client, on a trouvé son fichier `.env` en moins de cinq minutes. Il contenait les accès à la base de données de production. Une seule dork, et tout le système était compromis.

Le Google Dorking ne force aucune porte. Il se contente de regarder par les fenêtres que vous avez laissées ouvertes.

Comment utiliser le dorking de manière défensive (et légale)

C'est ici que mon expérience change de camp. Autant je trouve l'utilisation offensive illégale et dangereuse, autant l'utilisation défensive est un outil indispensable pour tout professionnel de la sécurité. C'est ce que j'appelle les "dorks défensives". L'idée est simple : utiliser les mêmes techniques que les attaquants, mais sur son propre périmètre ou sur celui de ses clients, avec leur autorisation.

J'ai mis en place une routine simple pour un client, un site e-commerce qui avait déjà subi une fuite de données. Chaque semaine, on lançait une série de dorks sur son domaine. L'objectif : détecter tout nouveau fichier sensible indexé. On cherchait les fichiers de configuration, les exports de base de données, les fichiers de log, les sauvegardes. En trois mois, on a trouvé et supprimé une douzaine de fichiers "orphelins" qui auraient pu causer de sérieux dégâts.

Quelques exemples de dorks défensives à adapter à votre propre domaine :

• `site:monsite.fr filetype:sql`
• `site:monsite.fr filetype:env`
• `site:monsite.fr filetype:log`
• `site:monsite.fr intitle:"index of"`
• `site:monsite.fr inurl:backup`

L'important, c'est la régularité. Ce n'est pas un test ponctuel, c'est un processus continu. Google indexe en permanence, et un fichier peut apparaître à tout moment. Un oubli, une mauvaise manipulation d'un développeur, et voilà votre `database.sql` exposé au monde entier.

Protéger son site avec robots.txt et la désindexation

La première ligne de défense, c'est le fichier `robots.txt`. Il permet d'interdire aux robots des moteurs de recherche d'explorer certaines parties de votre site. C'est une mesure de politesse pour les robots, pas un système de sécurité. Un attaquant qui connaît le chemin d'un fichier le téléchargera directement, sans passer par Google. Mais ça reste un premier filtre utile pour éviter que les fichiers sensibles soient indexés par mégarde.

Un exemple de configuration de base :

User-agent: *

Disallow: /admin/

Disallow: /backup/

Disallow: /config/

Disallow: /includes/

Il y a une autre astuce, plus radicale : la balise `

` dans le code HTML des pages sensibles. Elle demande explicitement aux moteurs de recherche de ne pas indexer la page. Mais attention, là encore, ce n'est pas une protection, c'est une demande.

Le vrai secret, celui que j'ai appris à mes dépens, c'est que la seule protection fiable est de ne pas mettre de fichier sensible sur un serveur web accessible. Si vous avez besoin de stocker un backup, il doit être hors de la racine du site, sur un serveur dédié ou dans un cloud privé. Pas dans un dossier `public_html`. J'ai vu trop de projets avec des mots de passe en clair dans `wp-config.php` pour ne pas insister là-dessus. C'est la base, mais c'est tellement souvent négligé.

Le cadre légal et éthique : où s'arrête la curiosité ?

Parlons franchement. Taper une dork comme `filetype:sql "password"` pour "voir" est une chose. Utiliser les résultats pour accéder à une base de données qui ne vous appartient pas en est une autre. La frontière est mince, mais elle est cruciale.

En France, la loi Godfrain (loi n°88-19 du 5 janvier 1988) réprime sévèrement l'accès frauduleux à un système de traitement automatisé de données (STAD). Le simple fait d'accéder à un système sans autorisation est un délit, puni de deux ans d'emprisonnement et de 60 000 euros d'amende. Si vous extrayez des données, les peines s'alourdissent. Le RGPD ajoute une couche supplémentaire, notamment en ce qui concerne la protection des données personnelles. En clair : récupérer et utiliser des données personnelles exposées est une violation de la loi, même si elles étaient "accessibles".

Anecdote personnelle : j'ai failli me faire piéger il y a quelques années. Je cherchais des informations sur une entreprise pour un projet, sans doute avec trop d'enthousiasme. J'ai trouvé un fichier Excel avec des listes de clients. J'ai hésité, je l'ai ouvert. Et puis j'ai réalisé que je n'avais aucune autorisation pour ça. J'ai fermé, et j'ai contacté l'entreprise pour leur signaler. C'est un réflexe à avoir : si vous trouvez une fuite, signalez-la et ne touchez à rien. Faire le bien commence par ne pas commettre le mal.

La règle est simple : si vous n'êtes pas mandaté pour tester un système, vous n'avez pas le droit d'y accéder. Même par accident.

Les limites de Google Dorking aujourd'hui

Ce n'est pas parce que Google est le moteur le plus utilisé qu'il est le plus puissant pour ce genre de recherche. En fait, Google a nettement durci sa politique. Il limite désormais certaines requêtes trop automatisées, et il a modifié son algorithme pour masquer un certain nombre de résultats jugés "sensibles". Les vieilles dorks qui fonctionnaient il y a dix ans sont devenues beaucoup moins efficaces.

Il y a aussi une question de fraîcheur de l'index. Google ne ré-indexe pas tout en temps réel. Un fichier peut rester visible dans les résultats plusieurs semaines après avoir été supprimé, ou au contraire, il peut ne jamais être indexé. C'est un facteur d'incertitude considérable.

Et puis, il y a le problème de la pertinence. Google est devenu très bon pour comprendre l'intention de recherche, mais il est aussi devenu plus agressif dans le nettoyage des résultats "poubelles". Beaucoup de dorks classiques renvoient désormais vers des sites de phishing ou des pages de spam, ce qui pollue les résultats.

Au-delà de Google : Shodan et Bing

Si Google est le couteau suisse de la recherche d'information, il existe des outils bien plus spécialisés pour trouver des systèmes exposés. C'est là que Shodan entre en jeu.

Shodan n'indexe pas les pages web comme Google. Il scanne l'ensemble des adresses IP publiques et indexe les bannières de services (HTTP, SSH, FTP, bases de données, etc.). Vous pouvez ainsi rechercher des serveurs qui répondent sur le port 21 (FTP), des bases de données MongoDB sans authentification, ou des caméras de surveillance. C'est un outil puissant, utilisé par les chercheurs en sécurité et les attaquants. La prise en main est plus complexe que Google, mais les résultats sont d'une précision redoutable.

Quant à Bing, il est parfois plus permissif que Google. Certaines requêtes qui sont filtrées ou tronquées chez Google fonctionnent encore chez Bing. Il a son propre langage de requêtes, avec des opérateurs similaires. Pour un audit complet, je vous conseille de toujours croiser les résultats des deux moteurs.

Voici un petit tableau comparatif pour y voir plus clair :

Outil	Indexe	Meilleur pour	Complexité
Google	Pages web, fichiers	Dorks classiques, fichiers indexés	Faible
Bing	Pages web, fichiers	Requêtes que Google filtre	Faible
Shodan	Adresses IP, services	Trouver des serveurs et appareils exposés	Moyenne à élevée

Se former et pratiquer de manière légitime : les bonnes ressources

Vous êtes curieux, vous voulez en savoir plus ? Très bien. Mais il faut le faire correctement. Ne vous lancez pas sur des cibles réelles "pour voir". La bonne méthode, c'est de s'entraîner sur des plateformes conçues pour ça, comme Hack The Box ou TryHackMe. Vous y trouverez des environnements vulnérables dans un cadre légal et contrôlé.

Pour le Google Dorking en particulier, il existe des sites qui recensent et classent les dorks, comme Exploit-DB (avec sa section "Google Hacking Database"). Ces listes sont une mine d'or pour comprendre les techniques, mais je vous le redis : ne les utilisez que sur votre propre infrastructure ou sur des cibles autorisées.

Enfin, la pratique défensive est un excellent terrain de jeu. Auditez votre propre site, cherchez vos propres fuites, configurez votre `robots.txt`. C'est un exercice concret, formateur, et qui vous servira tous les jours. J'ai fait mes armes comme ça, sur mes propres projets, et ça m'a permis d'acquérir les réflexes nécessaires sans jamais franchir la ligne rouge.

Le Google Dorking n'est ni un mythe ni une baguette magique. C'est un outil, comme un scalpel. Entre les mains d'un chirurgien, il sauve des vies. Entre celles d'un criminel, il tue. La différence ne tient pas à l'outil, mais à celui qui le manie et à son intention. La prochaine fois que vous ferez une recherche Google, posez-vous la question : qu'est-ce que je cherche vraiment, et ai-je le droit de le chercher ? La réponse à cette question fait toute la différence entre un expert en sécurité et un délinquant.