inurl:dork : guide complet pour hackers en compétition

inurl:dork : ce que tout participant à un hackathon doit savoir avant de s'asseoir

Mis à jour le 03/05/2026 par Inès Bertrand

La première fois qu'un de nos équipiers a tapé un inurl:dork dans un terminal lors d'un challenge OSINT, il a fait remonter en 40 secondes une ressource que l'organisateur pensait introuvable. Selon le rapport Verizon Data Breach Investigations de 2024, plus de 68 % des incidents de fuite d'information impliquent une phase de reconnaissance passive — et les Google Dorks en sont l'outil de prédilection. Si tu prépares un hackathon axé cybersécurité, OSINT ou data engineering, comprendre et maîtriser les inurl:dork n'est plus optionnel : c'est une compétence de base.

Qu'est-ce qu'un inurl:dork et pourquoi ça change tout ?

Un inurl:dork est une requête Google avancée qui exploite l'opérateur `inurl:` pour filtrer les résultats en recherchant un terme précis dans l'URL d'une page web — transformant le moteur de recherche en outil de reconnaissance structurée. Le terme « dork » vient de la communauté hacker des années 2000, popularisé par Johnny Long dans son ouvrage Google Hacking for Penetration Testers (Long, 2005), qui a littéralement fondé la discipline du Google Hacking.

En pratique, une requête du type `inurl:admin login` retournera toutes les pages indexées par Google dont l'URL contient à la fois "admin" et "login". Ce n'est pas de la magie : c'est de l'exploitation intelligente des métadonnées que Google collecte sur chaque URL. Dans le contexte d'un hackathon ou d'un challenge CTF (Capture The Flag), cette capacité à filtrer le web de façon chirurgicale peut faire la différence entre une équipe qui patine et une équipe qui soumet son flag en première.

Nous avons intégré ce module dans notre programme de préparation aux challenges OSINT sur hackathon-hi-paris.fr précisément parce que les participants qui arrivent avec une maîtrise des dorks progressent en moyenne deux fois plus vite sur les épreuves de reconnaissance que les autres.

Il faut distinguer trois composantes d'un inurl:dork efficace :

• L'opérateur : `inurl:`, `intitle:`, `filetype:`, `site:`, `cache:`, etc.
• Le terme cible : le mot ou la chaîne que tu cherches dans l'URL
• Les opérateurs combinés : l'assemblage de plusieurs filtres en une seule requête booléenne

Un dork sophistiqué ressemble à ceci : `inurl:"/wp-admin" filetype:php site:.fr` — trois filtres combinés qui restreignent les résultats aux pages PHP dans des répertoires /wp-admin sur des domaines français.

---

Comment fonctionnent les opérateurs Google Dorks ?

Les opérateurs Google Dorks exploitent l'index structuré de Google pour retourner des résultats impossibles à obtenir via une recherche classique en interrogeant des champs spécifiques des métadonnées de pages web. Google indexe bien plus que le contenu visible : il analyse les URLs, les balises meta, les noms de fichiers, les titres de pages, et les liens entrants.

Voici le tableau des opérateurs les plus utilisés en contexte OSINT et hackathon :

Opérateur	Fonction	Exemple de dork
`inurl:`	Terme dans l'URL	`inurl:login.php`
`intitle:`	Terme dans le titre HTML	`intitle:"index of"`
`filetype:`	Type de fichier spécifique	`filetype:pdf confidential`
`site:`	Restriction à un domaine	`site:gov.fr filetype:xls`
`cache:`	Version en cache de la page	`cache:example.com`
`intext:`	Terme dans le corps du texte	`intext:"mot de passe"`
`link:`	Pages pointant vers une URL	`link:hackathon-hi-paris.fr`
`related:`	Sites similaires	`related:github.com`

Selon la base de données GHDB (Google Hacking Database) maintenue par Offensive Security, plus de 6 800 dorks documentés sont répertoriés à ce jour, couvrant des catégories allant des fichiers sensibles exposés aux interfaces d'administration non protégées (Offensive Security, 2024).

L'opérateur `inurl:` est de loin le plus polyvalent parce qu'il cible la structure même des chemins d'URL — qui révèle souvent la technologie sous-jacente, la version d'un CMS, ou la hiérarchie d'un système de fichiers exposé par erreur. Un développeur qui nomme son répertoire `/api/v1/internal/` dit beaucoup sans le savoir.

"Le Google Hacking est probablement la technique de reconnaissance passive la plus sous-estimée dans la formation des développeurs. Elle ne nécessite aucun outil, aucune infrastructure — juste la capacité de formuler une question précise." — Marcus Hutchins, chercheur en cybersécurité (MalwareTech), 2023

---

Pourquoi les hackathons misent-ils sur les techniques OSINT ?

Les hackathons intègrent les techniques OSINT — dont les inurl:dork — parce qu'elles reflètent les compétences réelles demandées par les équipes de sécurité offensives et défensives dans les entreprises, et parce qu'elles testent à la fois la rigueur méthodologique et la créativité d'une équipe.

L'OSINT (Open Source Intelligence) est la collecte et l'analyse de données issues de sources publiquement accessibles. Dans un hackathon comme HI Paris, une épreuve OSINT typique peut demander à une équipe de reconstituer la surface d'attaque d'une infrastructure fictive en 90 minutes — exactement le type de sprint où la maîtrise des dorks devient un avantage compétitif direct.

Chiffres à retenir :

• 43 % des entreprises du CAC 40 auraient au moins un asset exposé identifiable via des Google Dorks simples, selon une étude Intrinsec de 2023
• Les challenges OSINT représentent désormais 31 % des épreuves des CTF majeurs en Europe, contre 18 % en 2020 (CTFtime.org, 2024)
• Une équipe formée aux techniques de dork résout en moyenne les épreuves de reconnaissance 47 % plus rapidement que des équipes non formées, d'après les statistiques internes de plusieurs organisateurs CTF francophones

Nous avons observé ce delta lors de nos propres éditions. L'an dernier, une équipe de cinq étudiants de l'École Polytechnique a remporté l'épreuve OSINT avec 20 minutes d'avance sur la deuxième place — leur avantage ? Ils avaient préparé une bibliothèque de dorks personnalisés adaptés aux environnements cloud et aux CMS courants.

La page dédiée aux challenges de la prochaine édition sur hackathon-hi-paris.fr détaille les catégories d'épreuves où les techniques OSINT seront évaluées.

---

Les inurl:dork les plus utiles pour un challenge CTF

Pour un CTF ou un hackathon axé sécurité, certains patterns de dork reviennent systématiquement. Les voici classés par cas d'usage :

Reconnaissance de technologies

• `inurl:"/phpinfo.php"` — expose les configurations PHP d'un serveur
• `inurl:".git" intitle:"index of"` — répertoires Git exposés publiquement
• `inurl:"/wp-content/uploads/" filetype:txt` — uploads WordPress non protégés

Détection de panneaux d'administration

• `inurl:"/admin/login.php"` — interfaces d'administration PHP classiques
• `inurl:"/administrator/index.php"` — Joomla non sécurisés
• `inurl:"/panel" intext:"password"` — panneaux avec champs sensibles visibles

Fichiers sensibles exposés

• `filetype:env inurl:".env"` — fichiers d'environnement avec variables sensibles
• `filetype:sql inurl:"dump"` — dumps de bases de données indexés
• `intitle:"index of" "backup"` — répertoires de sauvegardes accessibles

Recherche par plateforme

• `site:pastebin.com inurl:dork` — dorks publiés sur Pastebin
• `site:github.com inurl:"config.php" password` — configurations Git exposées

Il est fondamental de rappeler ici ce que Wikipedia définit clairement dans son article sur le Google Hacking : ces techniques sont légitimes dans un cadre autorisé (bug bounty, pentest contractuel, environnements de lab, CTF) et illégales si appliquées à des systèmes tiers sans autorisation explicite. Dans un hackathon, l'environnement est délimité et consenti — c'est précisément pourquoi c'est le lieu idéal pour pratiquer.

---

Comment pratiquer les Google Dorks de façon éthique ?

Pour pratiquer les inurl:dork de façon éthique, il faut travailler exclusivement dans des environnements consentis : plateformes de lab dédiées, challenges CTF officiels, programmes de bug bounty, ou infrastructures que tu possèdes toi-même. L'éthique ici n'est pas une posture — c'est une condition légale.

Voici les environnements recommandés pour s'entraîner :

• Hack The Box et TryHackMe : plateformes gamifiées avec des machines vulnérables intentionnellement
• PentesterLab : exercices ciblés sur l'OSINT et les techniques de reconnaissance
• OWASP WebGoat : application intentionnellement vulnérable pour pratiquer localement
• Les CTF officiels : les compétitions comme celles que nous organisons offrent un cadre légal et balisé

La règle d'or que nous appliquons dans tous nos ateliers : si tu n'as pas d'autorisation écrite, tu n'appliques pas ces techniques sur une infrastructure réelle. Ce n'est pas une restriction arbitraire — c'est ce qui différencie un professionnel de la sécurité d'un acteur malveillant.

Pour progresser méthodiquement, nous recommandons la démarche suivante :

1. Apprendre les opérateurs de base : maîtriser `inurl:`, `filetype:`, `intitle:` avant de combiner
2. Consulter la GHDB : la base de données de référence maintenue par Offensive Security
3. Construire ta propre bibliothèque : noter les dorks qui fonctionnent dans les contextes que tu rencontres
4. Chronométrer tes sessions : dans un CTF, la vitesse compte autant que la précision
5. Documenter les résultats : la trace de ta méthodologie vaut autant que le flag lui-même pour les organisateurs qui évaluent la qualité du travail

---

Intégrer les dorks dans ta stratégie hackathon

Dans la pratique d'un hackathon de 24 ou 48 heures, les inurl:dork ne sont pas une fin en soi — ils sont le point de départ d'une chaîne de reconnaissance qui va nourrir toutes les autres étapes de ton investigation ou de ton exploit.

Voici comment nous voyons les meilleures équipes intégrer les dorks dans leur workflow :

Phase 1 — Cartographie de la surface (0-15 min) Utiliser des dorks `site:` et `inurl:` pour identifier tous les assets publics de la cible fictive. Quels sous-domaines ? Quels fichiers exposés ? Quelle technologie ?

Phase 2 — Identification des vecteurs (15-45 min) Croiser les résultats avec des dorks `filetype:` et `intitle:` pour identifier des vecteurs potentiels : fichiers de configuration, interfaces d'admin, dépôts Git mal protégés.

Phase 3 — Exploitation et documentation (45 min — fin) Dans le cadre du challenge, exploiter les vecteurs identifiés tout en documentant chaque étape. Les organisateurs évaluent souvent autant la méthodologie que le résultat final.

Ce que j'aime dans les hackathons comme ceux que nous organisons chez HI Paris, c'est précisément ce moment où une équipe passe du slide "on va chercher des dorks" à un prototype de rapport de vulnérabilité complet — en moins d'une journée. La vitesse de passage de l'idée à l'exécution est toujours impressionnante.

---

Questions fréquentes

Q: Qu'est-ce qu'un inurl:dork exactement ? R: Un inurl:dork est une requête Google qui utilise l'opérateur `inurl:` pour trouver des pages dont l'URL contient un terme précis. Utilisé dans un contexte OSINT ou CTF, il permet de localiser des ressources exposées publiquement.

Q: Est-ce que les Google Dorks sont légaux ? R: Oui, dans un cadre autorisé. Effectuer des recherches Google est légal. Exploiter les résultats sur des systèmes tiers sans autorisation est illégal. Dans un hackathon ou un CTF, l'environnement est délimité et consenti, ce qui rend la pratique totalement légitime.

Q: Comment apprendre les inurl:dork pour un hackathon ? R: Entraîne-toi sur des plateformes comme Hack The Box, TryHackMe ou PentesterLab. Consulte la Google Hacking Database (GHDB) d'Offensive Security et construis ta propre bibliothèque de dorks classés par technologie.

Q: Quelle est la différence entre `inurl:` et `intitle:` ? R: `inurl:` cherche le terme dans l'URL de la page. `intitle:` le cherche dans la balise `