En 2024, une simple recherche Google a suffi à exposer les bases de données de 50 000 patients d'un hôpital français. Pas de hack sophistiqué, pas de malware. Juste une requête bien formulée, ce qu'on appelle un google dork. Depuis mon premier test il y a 6 ans sur un serveur personnel mal configuré, j'ai vu cette technique passer du statut de "curiosité de geek" à une menace réelle pour la sécurité des données. Et honnêtement, la plupart des gens sous-estiment totalement sa puissance.
Points clés à retenir
- Le google dorking exploite les opérateurs de recherche avancée de Google pour trouver des informations sensibles exposées involontairement.
- Les erreurs de configuration serveur sont la cause numéro 1 des données exposées via les dorks.
- Des documents comme les fichiers .env, les exports de base de données SQL, ou les logs d'erreur PHP sont des cibles privilégiées.
- Les entreprises peuvent se protéger via un fichier robots.txt bien paramétré et des audits réguliers avec des outils comme Shodan.
- La frontière entre test de sécurité autorisé et intrusion illégale est fine : un dork peut vous envoyer en prison si mal utilisé.
Qu'est-ce que le google dorking ?
Le google dorking, aussi appelé Google hacking, c'est l'art d'utiliser les opérateurs de recherche avancée de Google pour trouver des informations que le moteur a indexées mais que les propriétaires n'avaient pas l'intention de rendre publiques. Quand j'ai découvert ça en 2018 sur un forum de sécurité, j'ai passé une nuit entière à tester des requêtes. Résultat : j'ai trouvé le fichier de configuration d'un site e-commerce avec les identifiants de sa base de données en clair. J'aurais pu vider son catalogue. Franchement, ça fait froid dans le dos.
Pourquoi ça marche ?
Google indexe tout ce qu'il trouve sur le web. Les pages, les fichiers PDF, les documents texte, les exports de base de données... Si un fichier est accessible publiquement sans mot de passe, Google le voit et le stocke dans son index. Le problème ? Beaucoup de développeurs oublient de protéger certains répertoires. Une simple erreur de configuration serveur peut exposer des milliers de lignes de données clients. En 2026, avec l'explosion du nombre de sites web, le nombre de vulnérabilités potentielles a explosé aussi.
Mon premier dork : une leçon apprise dans la douleur
J'ai commencé avec une requête toute bête : filetype:sql "INSERT INTO". En 30 secondes, j'avais une liste de 15 exports de bases de données SQL. Le premier lien pointait vers un site de vente en ligne. J'ai téléchargé le fichier par curiosité. 12 000 adresses email, mots de passe hashés, et des adresses postales. J'ai immédiatement prévenu le propriétaire via un formulaire de contact. Sa réaction ? "Ce n'est pas possible, notre site est sécurisé." Eh bien non. Et ça m'a pris 5 minutes. Depuis, je fais toujours un test de google dorking sur mes propres projets avant de les mettre en ligne.
Les opérateurs essentiels pour des recherches avancées
Pour maîtriser le google dorking, il faut connaître les opérateurs de base. Les voici, avec des exemples concrets que j'utilise régulièrement lors de mes audits de sécurité.
| Opérateur | Fonction | Exemple d'utilisation |
|---|---|---|
site: | Limite la recherche à un domaine spécifique | site:monsite.com filetype:pdf |
filetype: | Cherche des fichiers d'un type précis | filetype:env DB_PASSWORD |
intitle: | Cherche un mot dans le titre de la page | intitle:"index of" /admin |
inurl: | Cherche un mot dans l'URL | inurl:wp-config.php |
ext: | Similaire à filetype, mais plus flexible | ext:log "error" |
cache: | Montre la version en cache d'une page | cache:exemple.com |
Un conseil que j'aurais aimé qu'on me donne plus tôt : combinez les opérateurs. Par exemple, site:gouv.fr filetype:xls "mot de passe" peut révéler des fichiers Excel sensibles sur des sites gouvernementaux. J'ai testé cette combinaison en 2023 sur un projet pour un client et j'ai trouvé un fichier contenant les mots de passe Wi-Fi d'une préfecture. Le client était vert.
Les dorks les plus pernicieux
Certaines requêtes sont particulièrement efficaces pour trouver des vulnérabilités web. En voici trois que j'utilise souvent :
inurl:"/wp-content/uploads/" filetype:sql– pour trouver des exports SQL dans les uploads WordPress.intitle:"phpMyAdmin" "Welcome to phpMyAdmin"– pour repérer des interfaces phpMyAdmin non protégées.filetype:env "DB_HOST" "DB_USER"– pour dénicher des fichiers de configuration Laravel ou Symfony.
Franchement, à chaque fois que je lance une de ces requêtes sur un site que je connais, je trouve au moins un truc. C'est effrayant. Et pourtant, la plupart des développeurs ne vérifient jamais ça.
Cibles classiques et vulnérabilités web
Quand on parle d'exploitation de données via le google dorking, certaines cibles reviennent tout le temps. Voici les plus courantes, basées sur mon expérience personnelle.
Les fichiers de configuration
Les fichiers .env, config.php, database.yml sont des mines d'or. Ils contiennent souvent des identifiants de base de données, des clés API, ou des secrets d'application. J'ai trouvé une fois un fichier .env avec une clé AWS qui donnait accès à un bucket S3 contenant 2 To de données clients. Le pire ? C'était un site de e-commerce qui traitait des paiements. J'ai prévenu l'équipe technique, qui a mis 3 semaines à corriger le problème. Pendant ce temps, n'importe qui pouvait télécharger les fichiers.
Les exports de base de données
Les exports SQL, CSV ou JSON sont souvent laissés dans des répertoires publics après une migration ou une sauvegarde. Une requête comme filetype:sql "DROP TABLE" peut en révéler des centaines. En 2025, j'ai participé à un bug bounty où j'ai trouvé un export CSV contenant 80 000 adresses email d'utilisateurs. Le site en question était une startup qui venait de lever 5 millions d'euros. Leur CTO m'a remercié en disant "on aurait dû faire un audit avant". Trop tard.
Les logs d'erreur
Les fichiers de log (error.log, debug.log) peuvent révéler des chemins de fichiers, des versions de logiciels, ou même des mots de passe en clair. J'ai trouvé une fois un log PHP qui contenait les mots de passe de connexion à une base de données MySQL, en clair, parce que le développeur avait utilisé mysqli_connect() avec les identifiants en dur dans le code. Une erreur de débutant, mais qui arrive encore en 2026.
Google dorking et sécurité informatique : le bon côté
Attention, le google dorking n'est pas qu'une technique de hacking. C'est aussi un outil précieux pour les professionnels de la sécurité informatique. Dans le cadre d'un audit de sécurité, c'est souvent la première chose qu'on fait. Pourquoi ? Parce que c'est rapide, gratuit, et que ça donne une idée immédiate de l'exposition d'un site.
Mon processus d'audit personnel
Quand un client me demande un audit, je commence toujours par une série de requêtes google dorking ciblées sur son domaine. Voici les étapes que je suis :
- Recherche de fichiers sensibles avec
site:client.com filetype:env OR filetype:sql OR filetype:log. - Vérification des répertoires ouverts avec
site:client.com intitle:"index of". - Recherche de pages d'administration exposées avec
site:client.com inurl:admin OR inurl:login. - Analyse des résultats et rapport au client.
Dans 70% des cas, je trouve au moins un problème. Et dans 30% des cas, c'est critique. Les clients sont souvent choqués. Mais au moins, ils peuvent corriger avant qu'un vrai hacker ne trouve la faille.
Les outils complémentaires
Le google dorking ne se limite pas à Google. Des outils comme Shodan (pour les appareils connectés) ou Wayback Machine (pour les versions anciennes de sites) peuvent aussi révéler des informations. J'utilise aussi un petit script Python que j'ai écrit pour automatiser les requêtes et noter les résultats. Mais attention : l'automatisation massive de requêtes Google peut faire bannir votre IP. Google n'aime pas les robots qui scannent son index.
Comment se protéger contre l'exploitation de données par dorking
Vous voulez éviter que vos données finissent dans un google dork ? Voici les mesures que j'applique systématiquement sur mes propres projets et que je recommande à tous mes clients.
Le fichier robots.txt
Le fichier robots.txt est votre première ligne de défense. Il indique aux moteurs de recherche quelles pages ne pas indexer. Exemple :
User-agent: *
Disallow: /wp-content/uploads/
Disallow: /backup/
Disallow: /config/
Mais attention : ça n'empêche pas un attaquant déterminé d'accéder aux fichiers directement via l'URL. C'est juste un frein pour Google.
La protection par mot de passe
Pour les répertoires sensibles, utilisez une authentification HTTP (htpasswd) ou un mot de passe au niveau de l'application. Ne comptez jamais sur l'obscurité (un nom de dossier bizarre) pour protéger vos données. J'ai vu des dossiers nommés "secret123" indexés par Google. Pas de chance.
Les audits réguliers
Faites un test de google dorking sur votre propre site tous les mois. Utilisez des outils comme Google Dork Scanner ou Site:Audit pour automatiser la vérification. En 2026, avec l'augmentation des cyberattaques, c'est devenu une pratique standard pour toute entreprise qui manipule des données sensibles. Si vous ne le faites pas, quelqu'un d'autre le fera à votre place.
Conclusion : un outil à manier avec responsabilité
Le google dorking est un outil fascinant, mais double tranchant. D'un côté, il permet de trouver des failles de sécurité que personne n'a remarquées. De l'autre, il peut exposer des données personnelles à des milliers de personnes si mal utilisé. Depuis que j'ai commencé à l'utiliser, j'ai appris une chose : la sécurité, ce n'est pas un produit qu'on achète, c'est une pratique qu'on applique tous les jours. Alors voici mon conseil : si vous êtes développeur ou responsable technique, prenez 30 minutes ce week-end pour lancer quelques requêtes google dorking sur votre propre site. Vous serez peut-être surpris. Et si vous trouvez quelque chose, corrigez-le immédiatement. Ne laissez pas vos données devenir le prochain dork à la une.
Questions fréquentes
Le google dorking est-il légal ?
Oui, tant que vous utilisez les informations trouvées à des fins de test de sécurité avec l'autorisation du propriétaire du site. Utiliser un dork pour accéder à des données sans autorisation est illégal et peut entraîner des poursuites pénales. J'ai vu des amis se faire arrêter pour ça. Ne jouez pas avec le feu.
Puis-je utiliser le google dorking pour trouver des mots de passe ?
Théoriquement, oui, si des mots de passe sont exposés dans des fichiers accessibles. Mais c'est illégal sans autorisation. Et honnêtement, si vous trouvez un mot de passe, prévenez le propriétaire plutôt que de l'utiliser. C'est plus éthique et ça vous évite des problèmes.
Comment savoir si mon site est vulnérable au google dorking ?
Faites une recherche avec des opérateurs comme site:monsite.com filetype:env ou site:monsite.com intitle:"index of". Si vous trouvez des fichiers sensibles, c'est qu'il y a un problème. Utilisez aussi des outils comme Dork Scanner pour automatiser la vérification.
Le google dorking fonctionne-t-il sur d'autres moteurs de recherche ?
Oui, des moteurs comme Bing, DuckDuckGo ou Yandex ont des opérateurs similaires. Mais Google reste le plus puissant grâce à son index massif. J'utilise parfois Bing pour des recherches croisées, mais Google reste mon outil principal.
Quels sont les risques si je ne protège pas mon site ?
Les risques incluent le vol de données clients, l'accès à des bases de données, la compromission de comptes administrateurs, et des attaques plus ciblées. En 2026, les attaquants utilisent le google dorking comme première étape de leurs attaques. Ne sous-estimez pas cette menace.