En 2023, un stagiaire en cybersécurité a découvert les identifiants de connexion d'une base de données gouvernementale en moins de 30 secondes. Son outil ? Une simple requête Google. Pas de brute force, pas de zero-day, pas d'exploit. Juste une chaîne de caractères bien placée. Voilà ce qu'est le google dorking : l'art de transformer un moteur de recherche en scanner de vulnérabilités.
Points clés à retenir
- Le google dorking utilise des opérateurs de recherche avancée pour exposer des données non protégées
- Les vulnérabilités web les plus courantes (fichiers exposés, pages d'admin, bases de données) sont souvent trouvables en quelques secondes
- La technique est légale pour la recherche, mais illégale si utilisée pour accéder à des données protégées
- Les entreprises doivent auditer régulièrement leur visibilité avec des dorks pour prévenir les fuites
- L'IA générative (Gemini, ChatGPT) commence à automatiser la création de dorks complexes
- En 2026, le google dorking reste l'un des vecteurs d'attaque les plus sous-estimés par les PME
Qu'est-ce que le google dorking ?
Le google dorking (aussi appelé Google hacking) consiste à utiliser des opérateurs de recherche avancée — site:, filetype:, intitle:, inurl: — pour trouver des informations que le propriétaire du site n'a jamais eu l'intention de rendre publiques. Un fichier Excel contenant les mots de passe des employés. Une page d'administration sans mot de passe. Un backup de base de données SQL accessible sans restriction.
J'ai testé cette technique sur mon propre site il y a deux ans, par curiosité. Résultat : j'ai trouvé un fichier .env que j'avais oublié sur un sous-domaine de staging. Dedans : les identifiants de ma base de production. Franchement, ça m'a glacé le sang. Depuis, je fais un scan de dorks tous les trimestres.
Pourquoi ça marche encore en 2026 ?
Google indexe tout ce qu'il trouve. Si un fichier est accessible sans authentification, Google l'indexe. Et si le fichier contient des informations sensibles, ces informations deviennent publiques via une simple recherche. Le problème ? La plupart des développeurs ne testent jamais ce que Google voit de leur site. Une étude de l'Institut Ponemon en 2025 estimait que 68 % des entreprises ayant subi une fuite de données avaient un fichier sensible indexé par Google au moment de l'incident.
Et le pire ? Les outils de sécurité traditionnels (firewalls, antivirus) ne détectent pas ce type d'exposition. Parce que ce n'est pas une attaque. C'est juste... Google.
Les opérateurs clés à maîtriser
Avant de foncer tête baissée, il faut connaître les bases. Voici les opérateurs que j'utilise le plus souvent dans mes propres audits.
| Opérateur | Fonction | Exemple |
|---|---|---|
site: | Limite la recherche à un domaine | site:monsite.com |
filetype: | Recherche un type de fichier spécifique | filetype:pdf |
intitle: | Cherche un mot dans le titre de la page | intitle:"index of" |
inurl: | Cherche un mot dans l'URL | inurl:admin |
intext: | Cherche un mot dans le contenu de la page | intext:"mot de passe" |
cache: | Affiche la version en cache d'une page | cache:example.com |
link: | Trouve les pages qui pointent vers une URL | link:example.com |
L'astuce que personne ne vous dit : combinez les opérateurs. site:monsite.com filetype:sql est infiniment plus puissant que chacun séparément. Et utilisez les guillemets pour les expressions exactes. Sans guillemets, Google cherche les mots séparément.
Les dorks les plus dangereux
Certains dorks sont tellement efficaces qu'ils sont presque devenus des classiques de la cybersécurité. En voici trois que j'ai testés et qui fonctionnent encore en 2026 :
intitle:"index of" "parent directory": trouve les répertoires ouverts sur les serveurs web. J'ai personnellement trouvé un dossier/backups/contenant des dumps de base de données datant de 2022 sur un site e-commerce français.inurl:wp-admin "login": localise les pages d'administration WordPress. Utile pour les tests de pénétration, mais aussi pour les attaquants qui cherchent des cibles faciles.filetype:env DB_PASSWORD: cherche les fichiers d'environnement contenant des mots de passe de base de données. Un classique qui rapporte encore des résultats.
Et là, surprise : en testant ce dernier dork sur un site client, j'ai trouvé un fichier .env avec un mot de passe MySQL en clair. Le client ne l'avait jamais su. Depuis, je recommande systématiquement un audit de dorks dans toute stratégie de site vitrine.
Scénarios d'exploitation concrets
Le google dorking n'est pas une théorie. C'est une pratique que j'ai vue à l'œuvre, des deux côtés du miroir.
Scénario 1 : le fichier de configuration oublié
Un développeur déploie une application sur un serveur de staging. Il copie un fichier config.php contenant les identifiants de la base de production. Il oublie de le supprimer. Google indexe le fichier. Un attaquant tape site:staging.example.com filetype:php DB_PASSWORD et trouve le fichier en 5 secondes. Résultat : fuite de données, notification à la CNIL, amende.
Ça vous semble tiré par les cheveux ? En 2024, une PME française de 50 salariés a subi exactement ce scénario. Le fichier était indexé depuis 18 mois. Personne ne l'avait vu.
Scénario 2 : les caméras de surveillance accessibles
Certaines caméras IP sont livrées avec une interface web accessible sans mot de passe. Google les indexe. Un dork comme inurl:"view/view.shtml" permet de trouver des flux vidéo en direct. J'ai testé il y a trois ans, par pure curiosité technique. J'ai vu l'intérieur d'un entrepôt logistique en région parisienne. Les employés ne savaient pas que leur caméra était visible par le monde entier.
Scénario 3 : les documents sensibles non protégés
Les fichiers PDF contenant des informations confidentielles (bilans financiers, contrats, données clients) sont souvent indexés sans restriction. Un dork comme site:example.com filetype:pdf "confidentiel" peut révéler des documents que l'entreprise pensait privés. J'ai personnellement trouvé un rapport d'audit interne complet d'une entreprise du CAC 40 via cette technique. Le fichier était sur un sous-domaine non référencé.
Comment se protéger
Si vous êtes propriétaire d'un site web, vous n'êtes pas impuissant. Voici les mesures que j'applique systématiquement après avoir découvert mes propres fuites.
Auditer régulièrement sa visibilité
Utilisez Google vous-même pour chercher ce que Google voit de votre site. Tapez site:votresite.com et parcourez les résultats. Cherchez les fichiers sensibles : .env, .sql, .bak, config.php. Si vous trouvez quelque chose, demandez à Google de le supprimer via la Search Console. Et surtout, corrigez la cause : protégez ces fichiers par mot de passe ou déplacez-les hors du répertoire web.
Un conseil : faites cet audit au moins une fois par trimestre. Les développeurs oublient des fichiers. Les mises à jour en laissent traîner. Et Google indexe vite.
Utiliser le fichier robots.txt avec précaution
Le fichier robots.txt peut empêcher Google d'indexer certaines parties de votre site. Mais attention : il ne les rend pas inaccessibles. Un attaquant qui connaît l'URL peut toujours y accéder. Le robots.txt est une barrière de convenance, pas de sécurité.
Pour les fichiers vraiment sensibles, utilisez l'authentification HTTP ou déplacez-les hors du répertoire racine. Et ne mettez jamais de mots de passe dans des fichiers accessibles via le web. Jamais.
Activer la surveillance des dorks
Des outils comme Google Alerts ou des services spécialisés (comme DorkScanner ou Shodan) peuvent vous alerter si de nouveaux dorks ciblant votre domaine apparaissent. J'utilise personnellement un script Python qui exécute une liste de dorks toutes les semaines et m'envoie un rapport par email. Ça m'a déjà évité au moins deux fuites potentielles.
Et si vous voulez aller plus loin, intégrez cette surveillance dans votre stratégie de contenu SEO : les pages sensibles indexées nuisent à votre image de marque.
Google dorking et IA : le nouveau terrain de jeu
En 2026, l'IA générative change la donne. Gemini, ChatGPT et autres LLMs peuvent générer des dorks complexes en langage naturel. Vous tapez "trouve les fichiers de configuration exposés sur le site example.com" et l'IA vous sort une combinaison d'opérateurs que vous n'auriez jamais imaginée.
J'ai testé avec Gemini récemment. Je lui ai demandé : "génère un dork pour trouver des fichiers de backup SQL sur un sous-domaine de staging". En moins de 10 secondes, j'avais une requête prête à l'emploi : site:*.staging.example.com filetype:sql "INSERT INTO". Efficace. Très efficace.
Mais attention : l'IA ne fait que ce qu'on lui demande. Si vous ne savez pas ce que vous cherchez, elle ne vous aidera pas. Le google dorking reste un art qui demande de la réflexion et de la connaissance des systèmes cibles. L'IA est un accélérateur, pas un remplacement.
Et ça pose une question intéressante : si les attaquants utilisent l'IA pour trouver des vulnérabilités, les défenseurs doivent faire de même. C'est le principe du GEO (Generative Engine Optimization) : optimiser ses contenus pour qu'ils soient cités par les IA, mais aussi pour qu'ils ne soient pas exposés. Un sujet que j'aborde dans mon article sur le GEO comme atout incontournable.
Le google dorking est-il légal ?
Question piège. La technique en elle-même est légale : utiliser Google pour chercher des informations publiques n'est pas un crime. Le problème, c'est l'intention et l'action. Si vous trouvez un fichier contenant des mots de passe et que vous y accédez, vous entrez dans une zone grise juridique. En France, l'accès frauduleux à un système de traitement automatisé de données (STAD) est puni de 2 ans d'emprisonnement et 60 000 € d'amende (Article 323-1 du Code pénal).
Mon conseil : utilisez le google dorking uniquement sur vos propres sites ou avec une autorisation écrite. Ne testez jamais sur des sites que vous ne possédez pas. J'ai vu des stagiaires enthousiastes se faire virer pour avoir "testé" des dorks sur des sites concurrents. Pas de blague avec ça.
Maîtriser le google dorking pour mieux se défendre
Le google dorking n'est pas une technique obscure réservée aux hackers. C'est un outil de diagnostic que tout professionnel de la sécurité (et tout propriétaire de site) devrait connaître. En 2026, avec l'explosion des données et la multiplication des sous-domaines oubliés, les fuites via Google sont plus fréquentes que jamais.
Alors, quelle est la prochaine action ? Ouvrez Google, tapez site:votredomaine.com et parcourez les résultats. Si vous trouvez quelque chose qui ne devrait pas être là, agissez. Supprimez le fichier, protégez-le, et mettez en place une surveillance régulière. Et si vous voulez approfondir, commencez par maîtriser les opérateurs de base. Le reste viendra avec la pratique.
Un dernier conseil : ne sous-estimez jamais ce que Google voit de vous. Parce que si vous ne le cherchez pas, quelqu'un d'autre le fera.
Questions fréquentes
Le google dorking est-il réservé aux experts en cybersécurité ?
Pas du tout. Les opérateurs de base (site:, filetype:, intitle:) sont simples à comprendre et à utiliser. La difficulté vient de la combinaison des opérateurs et de la connaissance des systèmes cibles. Un débutant peut trouver des fichiers sensibles en quelques minutes, mais un expert saura où chercher et quoi faire des résultats.
Comment savoir si mon site est vulnérable au google dorking ?
La méthode la plus simple : tapez site:votresite.com dans Google et parcourez les résultats. Cherchez les fichiers sensibles (backup, config, sql, env) et les pages d'administration. Si vous trouvez quelque chose qui ne devrait pas être public, vous avez une vulnérabilité. Utilisez aussi des dorks spécifiques comme site:votresite.com filetype:sql ou site:votresite.com inurl:admin.
Google peut-il empêcher le google dorking ?
Techniquement, Google pourrait limiter certains opérateurs, mais cela nuirait à l'expérience de recherche légitime. Google propose plutôt des outils comme la Search Console pour que les propriétaires de sites contrôlent ce qui est indexé. La responsabilité repose sur les propriétaires de sites, pas sur Google.
Quels sont les types de fichiers les plus dangereux à exposer ?
Les fichiers .env (variables d'environnement avec mots de passe), .sql (dumps de base de données), .bak (fichiers de sauvegarde), config.php (configuration d'application), et les fichiers PDF contenant des informations confidentielles. Les répertoires ouverts (index of) sont aussi très dangereux car ils exposent l'arborescence complète du serveur.
Le google dorking fonctionne-t-il sur d'autres moteurs de recherche ?
Oui, mais avec des variations. Bing, DuckDuckGo et Yandex ont leurs propres opérateurs. Bing utilise par exemple site: et filetype: de manière similaire. DuckDuckGo est plus limité. Pour une couverture maximale, il faut tester sur plusieurs moteurs. Mais Google reste le plus utilisé et le plus puissant pour cette technique.