Base de données Google Hacking (GHDB) : de quoi s'agit-il et comment l'utiliser à des fins défensives ?
Table des matières
Si vous êtes déjà tombé sur un ‘ Google dork » dans un compte rendu et que vous vous êtes demandé où l'auteur l'avait trouvé, la réponse est presque toujours la même : la base de données de piratage Google (Google Hacking Database).
La GHDB est la bibliothèque publique de référence des requêtes de recherche Google qui révèlent des informations exposées en ligne. Active depuis 2004, elle héberge actuellement des milliers de dorks catalogués répartis en 14 catégories et constitue le fondement de davantage de travaux de reconnaissance, tant par des attaquants que par des défenseurs, que toute autre ressource unique sur Internet.
Cet article concerne la question qui suit : Qu'est-ce que la GHDB, comment est-elle structurée et comment votre équipe de sécurité doit-elle réellement l'utiliser ?
Qu'est-ce que la base de données de piratage Google ?
La base de données Google Hacking (GHDB) est un répertoire public et consultable de Google dorks — requêtes de recherche avancées qui utilisent les opérateurs de Google pour trouver des informations sensibles indexées par le moteur de recherche.
Chaque entrée de la base de données comprend la chaîne de recherche elle-même, la catégorie d'information qu'elle met en évidence (telle que les portails de connexion, les bases de données exposées, les fichiers sensibles), une courte description et la date à laquelle elle a été soumise. Ensemble, ces entrées forment une bibliothèque fonctionnelle de toutes les manières documentées dont une recherche Google a déjà été utilisée pour trouver quelque chose qu'elle n'aurait probablement pas dû.
La GHDB n'est pas un outil de piratage au sens strict. Elle n'exécute aucun code. Elle n'exploite rien. C'est un catalogue — mais c'est un catalogue d'erreurs humaines à l'échelle d'Internet, ce qui en fait l'une des ressources les plus puissantes de la boîte à outils OSINT.
Qui est Johnny Long et comment a débuté la GHDB ?
La GHDB a été créée en 2004 par le chercheur en sécurité Johnny Long, l'un des premiers spécialistes de ce qu'il a appelé le “ piratage Google ”, consistant à utiliser les moteurs de recherche comme des outils de reconnaissance plutôt que comme des portails vers du contenu Web.
Long a popularisé le concept dans son livre Google Hacking pour les testeurs d'intrusion, qui est devenu le texte fondamental sur le sujet. Parallèlement au livre, il a créé et entretenu une liste publique de dorks soumis, les classant selon ce qu'ils exposaient et la manière dont ils pouvaient être utilisés. La communauté a contribué aux entrées, Long les a sélectionnées et le GHDB est passé d'un projet personnel à une référence reconnue.
En 2010, Long a confié la maintenance de la base de données à Sécurité offensive, la même équipe derrière Kali Linux et la certification OSCP. La GHDB est hébergée sur leur Base de Données d'Exploits (Exploit-DB) depuis lors, où elle continue d'accepter les soumissions de la communauté et de les organiser selon la structure de catégories d'origine.
La passation fait partie de ce qui confère au GHDB sa longévité. Il est maintenu en continu, modéré de manière professionnelle et intégré aux outils de pentesting grand public depuis plus de deux décennies.
Où le GHDB est-il hébergé aujourd'hui ?
Le siège actuel du GHDB est exploit-db.com/google-hacking-database, exploité par Offensive Security. L'interface est simple : une liste d'entrées filtrable, consultable par mot-clé, catégorie, auteur et date.
La plupart des outils de reconnaissance professionnels intègrent également directement la GHDB. Le Metasploit Framework comprend un module de recherche qui extrait les requêtes de la base de données. Recon-ng peut récupérer les entrées de la GHDB via son système de modules. Les distributions axées sur l'OSINT telles que Kali Linux et BlackArch sont livrées avec des outils compatibles avec la GHDB préinstallés.
Vous pouvez également naviguer dans la GHDB sans compte Exploit-DB, ce qui explique en partie pourquoi il s'agit d'une ressource si facile d'accès tant pour les attaquants que pour les défenseurs. N'importe qui disposant d'un navigateur peut consulter l'intégralité du catalogue en quelques secondes.
Les 14 catégories du GHDB expliquées
La GHDB colonne vertébrale structurelle est son système de catégories. Chaque dork soumis est classé dans l'une des 14 catégories, chacune correspondant à une classe d'exposition. Comprendre ces catégories est le moyen le plus rapide d'utiliser efficacement la base de données : au lieu de faire défiler des milliers d'entrées, vous allez directement au type de risque qui s'applique à votre environnement.
| Catégorie GHDB | Ce qu'il fait remonter | Implication défensive |
|---|---|---|
| Points d'appui | Points d'entrée initiaux — shells exposés, points d'injection de commandes, scripts d'administration accessibles. | Auditer les applications web pour y détecter des points de terminaison administratifs oubliés. |
| Fichiers contenant des noms d'utilisateur | Fichiers journaux, vidages et fichiers de configuration qui incluent des noms d'utilisateur valides. | Traitez les noms d'utilisateur comme des données semi-sensibles : ils alimentent les attaques par pulvérisation de mots de passe. |
| Répertoires sensibles | Listes de répertoires ouverts (Index de /) révélant les structures de fichiers internes. | Désactivez l'affichage des répertoires au niveau du serveur web. Ne comptez pas sur l'obscurité. |
| Détection de serveur Web | Pages et bannières par défaut qui révèlent le logiciel et la version du serveur. | Supprimer les bannières du serveur. Remplacer les pages d'accueil par défaut. |
| Fichiers vulnérables | Fichiers associés à des CVE connues — plugins CMS obsolètes, scripts exploitables. | Hygiène des correctifs et gestion des versions au niveau de la couche application. |
| Serveurs vulnérables | Vulnérabilités au niveau du serveur détectables par recherche. | Inventaire des actifs et analyse continue des vulnérabilités. |
| Messages d'erreur | Erreurs d'application verbeuses qui divulguent des traces de pile, des chemins et la structure de la base de données. | La production ne doit jamais afficher d'erreurs de débogage. Interceptez-les et journalisez-les silencieusement. |
| Fichiers contenant des informations croustillantes | Tout ce qui est sensible et ne rentre nulle part ailleurs — documents internes, projets de politiques, données RH. | Examinez le contenu de votre répertoire racine web public. Appliquez ne pas indexer les en-têtes appropriés. |
| Fichiers contenant des mots de passe | Des fichiers contenant littéralement des mots de passe en clair ou hachés. | Gestion des secrets, point final. Pas d'identifiants dans le code source. |
| Informations sensibles sur les achats en ligne | Données clients, registres de commandes, informations de paiement provenant de systèmes de commerce électronique mal configurés. | Revue du périmètre PCI. Segmentation du stockage. |
| Données de réseau ou de vulnérabilité | Journaux de pare-feu, sortie IDS, fichiers de configuration réseau. | Les données de surveillance internes ne doivent jamais se retrouver dans un répertoire accessible au public. |
| Pages contenant des portails de connexion | Panneaux d'administration, tableaux de bord internes, portails VPN exposés au web public. | MFA sur chaque surface de connexion. Restreindre les chemins d'administration par IP. |
| Divers appareils en ligne | Appareils IoT, caméras, imprimantes, interfaces ICS exposés à Internet. | Segmentation du réseau. Les appareils ne doivent pas être accessibles publiquement par défaut. |
| Avis et vulnérabilités | Dorks liés à des avis de sécurité publiés — moyen rapide de trouver des instances non corrigées. | Considérez les nouveaux avis comme des opportunités de chasse immédiates, et non comme de la paperasse. |
Les étiquettes de catégories datent de plusieurs décennies, mais les types d'exposition qu'elles décrivent restent intemporels. Un serveur Web divulgue toujours sa bannière de la même manière qu'en 2008. Un Index de / révèle toujours les mêmes types de fichiers. Les technologies changent, les erreurs de configuration ne changent pas.
Comment les attaquants utilisent la GHDB
Pour les attaquants, la GHDB est un point de départ, et non un manuel prêt à l'emploi. Les acteurs malveillants l'utilisent généralement selon l'un de ces trois modes.
Targeted reconnaissance. Given a specific target organization, an attacker will pull dorks from relevant categories — login portals, exposed devices, vulnerable files — and append site:targetdomain.com to each one. A single afternoon of this work can yield a complete picture of an organization‘s misconfigurations, forgotten subdomains, and exposed administrative interfaces.
Opportunistic sweeps. Instead of targeting a specific organization, attackers run broad GHDB queries across the open web — inurl:phpmyadmin/index.php returns every exposed phpMyAdmin instance on the internet, regardless of who owns it. The output becomes a target list, sorted by which look easiest to exploit.
Advisory chasing. When a new CVE is published, attackers immediately look for a GHDB dork that surfaces vulnerable instances of the affected software. The race is between defenders patching and attackers finding unpatched instances through search. Search usually wins, because it scales faster than human patching schedules.
Our breakdown of Google dorking in real attacks walks through six documented use cases that follow exactly these patterns — including a ransomware incident that began with a single GHDB-style search.
Comment les défenseurs doivent utiliser la GHDB
The GHDB is just as useful, arguably even more useful, for the defender‘s side of the chair. The asymmetry that makes it dangerous in attacker hands becomes a strength when you turn it inward.
Defensive use of the GHDB falls into three buckets:
Continuous self-audit. Take the dorks in the categories most relevant to your environment (Pages Containing Login Portals, Vulnerable Files, Files Containing Passwords) and append site:yourdomain.com to each one. Run them weekly. Anything Google has indexed about you, an attacker can find — so finding it first is the only winning move.
Advisory response. When a CVE drops for software your organization uses, check whether a corresponding GHDB entry exists or has been recently submitted. If one does, assume opportunistic scanning has already started. Patch on attacker time, not vendor time.
Red team support. Internal red teams and authorized pentesters can use the GHDB to scope realistic recon exercises. The goal isn‘t to find something exotic; it‘s to verify that nothing in the well-known catalogue applies to you.
For organizations without dedicated red teams, services like CybelAngel‘s gestion de la surface d'attaque automate this kind of continuous self-audit — running structured queries across the open web and surfacing exposures tied to your domain before attackers spot them.
Élaboration d'un flux de travail GHDB défensif
A one-off GHDB sweep finds yesterday‘s exposures. The leaks that hurt are the ones that get indexed after your last audit. To turn the GHDB into an ongoing control:
- Build your category shortlist. Of the 14 categories, three to five will dominate your risk profile. For most organizations, that‘s Pages Containing Login Portals, Files Containing Passwords, Sensitive Directories, Web Server Detection, and Various Online Devices. Map your own list once, then stop questioning it.
- Maintain a domain-pinned dorks library. Take each relevant GHDB query, hard-code your domain into it (
site:yourcompany.com), and store the result as a runbook. The library lives in version control, gets reviewed quarterly, and runs on a schedule. - Automate the execution. Tools like Recon-ng, theHarvester, and the Metasploit search modules can run GHDB queries programmatically. Output flows into your ticketing or SIEM system, not a researcher‘s notebook.
- Trigger on advisories. When a new CVE drops for software you run, your workflow should check the GHDB for a corresponding entry within hours, not weeks.
- Track time-to-remediation. Every finding gets a clock. The lag between detection and rotation/patching is the single best indicator of how well the workflow is actually working.
- Loop in development teams. Most GHDB findings point to a process gap — a
ne pas indexerheader that wasn‘t set, a.bakfile that shouldn‘t be in the web root, a default admin path that was never renamed. Fix the process, not just the artefact.
GHDB et considérations éthiques
Browsing the GHDB is legal. Submitting entries to it is legal. Running queries from it against your own domain is legal.
Running them against a domain you don‘t own — and then acting on the results — is where things change. Under the Computer Fraud and Abuse Act in the US, the Computer Misuse Act in the UK, and equivalent legislation in most jurisdictions, accessing systems or data you don‘t have authorization to touch is a criminal offense, regardless of how easy it was to find them through Google.
Ethical use of the GHDB requires:
- Authorization. Only run queries against your own assets, or assets explicitly scoped in an engagement contract or bug bounty program.
- Restraint. Reading a publicly indexed file is generally legal. Logging in with credentials you found in it is not.
- Responsible disclosure. If you find someone else‘s exposure incidentally, report it through their security disclosure channel. Don‘t exploit it. Don‘t share it publicly until they‘ve had time to remediate.
The GHDB itself is a defensive resource that happens to be useful offensively. How you use it determines which side you‘re on.
Limites de la GHDB en 2026
The GHDB is a venerable resource, but it‘s not a complete one. Several limitations are worth knowing:
Submission lag. The database depends on community submissions. Novel exposure patterns may not appear for weeks or months after they start being exploited in the wild.
Google‘s changes. Google has deprecated several operators over the years — cache : was retired in 2024, lien : has been unreliable since 2017, and + no longer forces exact matches. Older GHDB entries that rely on deprecated operators no longer work as written. Always test before relying.
Coverage gaps. The GHDB focuses on Google. It does not cover Bing, DuckDuckGo, Yandex, or specialist engines like Shodan and Censys — all of which surface different exposure classes. A defender relying on the GHDB alone has visibility into one search index.
Volume signal-to-noise. Some categories contain thousands of entries. Without filtering by relevance to your environment, you can spend more time triaging the database than triaging your actual exposures.
This is why most mature security programs treat the GHDB as one input to a broader exposure-monitoring strategy — not as the strategy itself.
Conclusion
Every query in the GHDB is a search an attacker can run against your domain right now. CybelAngel continuously monitors your external attack surface for the exposures the GHDB finds, and alerts your security team before an attacker acts on them.
FAQ
\
À propos de l'auteur
