Comment choisir votre première cible bug bounty : le système des 3 filtres

TL;DR

La plupart des débutants n'abandonnent pas le bug bounty par manque de compétences. Ils abandonnent parce qu'ils choisissent la mauvaise cible. Le choix de la cible est une compétence qui s'apprend, et elle compte davantage que de connaître chaque payload. Faites passer chaque programme par trois filtres avant d'y consacrer une seule heure :

1. Taille du scope. Choisissez une cible que vous pouvez cartographier entièrement en moins de 30 minutes.
2. Stack technique. Chassez les technologies que vous maîtrisez déjà.
3. Densité de chasseurs. Choisissez des programmes où vous affrontez cinq chasseurs, pas cinq mille.

Déroulez ensuite une checklist de recon de 2 heures, notez la cible sur 30 et engagez-vous sur une seule cible pendant quatre semaines. C'est ainsi que vous atteignez la compréhension profonde où vivent les vrais bugs.

Le choix de la cible est la compétence que personne n'enseigne

Voici la vérité que personne ne vous dit. La plupart des débutants n'abandonnent pas le bug bounty parce qu'ils ne sont pas assez intelligents. Ils abandonnent parce qu'ils ouvrent un programme au scope énorme, passent des semaines à lancer des scanners automatisés, ne trouvent rien et concluent qu'ils ne sont pas faits pour ce domaine.

Le choix de la cible est une compétence. Elle compte davantage que de connaître chaque payload XSS. Elle compte davantage que d'avoir vingt outils installés. Quand vous choisissez une cible adaptée à votre niveau actuel, vous trouvez des bugs. Quand vous choisissez une cible trop grande, trop complexe ou trop saturée, vous vous épuisez.

J'ai appris cela à mes dépens. Au début de ma carrière, je chassais tout ce qui avait une prime attachée. J'ai gaspillé des mois sur des cibles trop grandes, trop complexes ou trop saturées. Dès que j'ai commencé à filtrer les cibles avant de les tester, mes résultats ont changé immédiatement. C'est cette discipline qui m'a permis d'atteindre plus de 250 entrées au Hall of Fame d'organisations comme l'OMS, l'UNESCO, la BBC, Boeing, Cambridge, Sheffield, Deutsche Börse, BASF, Michelin et Philips.

Ce guide transforme cette discipline en un système simple et reproductible. Le système des 3 filtres n'est pas compliqué et ne demande pas d'outils avancés. Il demande juste d'être honnête sur votre niveau actuel en tant que chasseur. Faites passer chaque cible potentielle par ces trois vérifications. Si une cible échoue à l'une d'elles, laissez-la tomber et trouvez-en une autre.

1. Filtre 1 : taille du scope (pouvez-vous la cartographier en 30 minutes ?)

Pour vos dix premiers bugs, choisissez un scope qui tient sur un seul écran. Évitez les scopes wildcard comme *.target.com lorsque vous débutez. Cherchez des scopes ciblés comme api.target.com, dashboard.target.com, ou des endpoints et sous-domaines précis listés dans la politique du programme.

Pourquoi la taille du scope détermine vos chances

Un scope wildcard est un piège pour les débutants. Vous passerez deux semaines à cartographier des milliers de sous-domaines. Vous trouverez un vieux serveur, vous vous emballerez, puis vous découvrirez que quelqu'un l'a signalé il y a deux jours grâce à l'automatisation. Vous venez de passer quatre-vingts heures pour apprendre qu'un autre chasseur est plus rapide que vous.

Les grands scopes créent aussi de la fatigue décisionnelle. Quand vous avez dix mille sous-domaines, vous ne développez jamais de compréhension profonde d'une seule application. Vous sautez d'actif en actif. Or les bugs de logique vivent dans la compréhension profonde. Les IDOR, les race conditions et la manipulation de prix sont trouvés par des testeurs qui comprennent le flux métier mieux que les développeurs.

Voyez les choses ainsi. Si on vous demandait de trouver une erreur dans un seul chapitre d'un livre, vous y arriveriez en une heure. Si on vous demandait de trouver une erreur quelque part dans une bibliothèque entière, vous erreriez pendant des jours et la rateriez probablement. C'est exactement ce qui arrive quand les débutants chassent des scopes wildcard. Le bug est là, mais vous cherchez à trop d'endroits à la fois.

Un scope ciblé vous oblige à comprendre chaque fonctionnalité. Vous apprenez comment les utilisateurs s'inscrivent, comment circulent les commandes, comment les paiements sont traités et comment les fichiers sont partagés. C'est là que se cachent les vrais bugs. Quand vous connaissez chaque endpoint par cœur, vous commencez à remarquer les comportements bizarres : ce paramètre qui change de comportement quand vous le modifiez, cet endpoint qui ne vérifie pas correctement les permissions. Ces instants n'arrivent que lorsque vous connaissez l'application en profondeur.

À quoi cela ressemble dans la vraie vie

Un chercheur en sécurité a partagé son expérience sur Reddit après huit mois d'échecs. C'était un développeur web doté de solides connaissances techniques. À chaque fois qu'il se lançait dans une chasse, il listait tous les sous-domaines d'une grande cible puis les parcourait au hasard. Il utilisait des outils d'énumération de sous-domaines, des crawlers et des récupérateurs d'URL d'archives. Après avoir trouvé des endpoints, il ne savait pas quoi faire ensuite. Il a écrit qu'il avait l'impression de devoir passer une année entière juste pour trouver un tout petit bug. Il chassait des scopes énormes sur des programmes populaires sans plan, et la taille de la cible l'a complètement submergé. Vous pouvez lire le fil ici : Bug bounty is insanely hard. Am I doing something wrong?

Un autre chasseur a parlé de l'erreur qui a ralenti sa progression pendant des mois. Il courait après les énormes programmes aux larges scopes, changeait de cible tous les quelques jours et ne s'engageait jamais à comprendre une application en profondeur. Dès qu'il s'est concentré sur des scopes plus petits et gérables, ses résultats ont changé immédiatement : The Bug Hunting Mistake That Slowed My Progress.

Les scopes idéaux pour les débutants

• api.target.com ou mobile.target.com avec peu de sous-domaines et d'actifs
• Des endpoints précis comme /api/v1/users ou /api/v1/orders
• Des applications uniques avec des rôles utilisateurs clairs
• Des boutiques en ligne avec des flux de panier et de paiement

La règle : si vous ne pouvez pas lire chaque endpoint du scope en trente minutes, la cible est trop grande. Passez votre chemin.

2. Filtre 2 : stack technique (chassez ce que vous comprenez)

Choisissez des cibles dont vous comprenez la logique et le protocole. Si vous n'avez jamais touché à GraphQL, ne choisissez pas une cible dont toute l'API est native GraphQL. Si vous ne comprenez pas les applications mobiles, laissez les scopes mobiles de côté pour l'instant. Vous pourrez apprendre ces technologies plus tard, mais ce n'est pas par là que vous commencez. Chassez ce que vous connaissez.

Pourquoi une inadéquation technique tue la motivation

Quand vous choisissez une cible bâtie sur une technologie que vous ne comprenez pas, vous passez votre première semaine à apprendre la syntaxe au lieu de trouver des bugs. Vous passez votre deuxième semaine à vous battre avec les concepts. À la troisième semaine, vous êtes frustré et prêt à abandonner.

Les débutants courent souvent après les grosses primes sur des cibles difficiles. Une prime maximale de 50 000 $ ne sert à rien si l'application tourne sur une stack que vous ne savez pas tester. Facebook, Google et Apple ont une sécurité de classe mondiale et sont testés par les meilleurs chasseurs depuis plus de dix ans. En tant que débutant, vous risquez de passer cent heures et de ne rien trouver.

Comparez cela à un chasseur qui comprenait les API REST et les formulaires web standard et qui a trouvé un bug de manipulation de prix sur un simple site PHP. L'API de paiement était une basique requête POST. Pas de microservices, pas d'architecture complexe, juste un paramètre de prix envoyé depuis le client. Il a changé le prix de cinq cents dollars à deux dollars, et le serveur l'a accepté. Ce bug n'a demandé aucun code d'exploit ni payload spécial. Il a juste demandé de comprendre une simple requête POST et de se demander pourquoi le prix venait du client. C'est une vulnérabilité de logique métier classique, et c'est exactement le genre de bug que vous pouvez trouver quand votre esprit est libre de chercher des failles de logique au lieu de se battre avec les bases.

Cas réel : la barrière GraphQL

Un débutant a raconté publiquement l'histoire de sa première prime. Il a trouvé un fichier JavaScript contenant une clé d'API GraphQL sur une cible au scope énorme, et a découvert un endpoint /graphql via du fuzzing de répertoires. Mais il y avait un problème : il ne connaissait rien à GraphQL. Il a passé plusieurs jours à faire des recherches, à apprendre et à rassembler des outils juste pour comprendre le schéma. Il a utilisé PortSwigger Academy pour apprendre les bases et l'extension Burp InQL pour visualiser le schéma. Il a fini par décrocher une prime de 700 $, mais le fossé technologique a failli le faire abandonner avant même de commencer. S'il avait choisi une cible avec une API REST standard, il aurait pu commencer à tester immédiatement. Histoire complète : How I Got My First Bounty.

Les stacks adaptées aux débutants

• API REST standard avec des endpoints GET et POST clairs (voir notre guide de test de sécurité des API)
• Applications web classiques avec des rôles utilisateurs comme Admin, User et Guest
• Flux e-commerce avec étapes de panier, paiement et règlement
• Plateformes dotées de fonctionnalités d'équipe ou d'invitation

Les stacks à éviter en tant que débutant

• Forte dépendance aux WebSockets. Difficile à tester sans outillage sur mesure.
• GraphQL avec autorisation complexe. Courbe d'apprentissage abrupte.
• Scopes Internet des objets ou matériel. Nécessite des appareils physiques.
• Scopes blockchain ou smart contracts. Un tout autre ensemble de compétences.

Si vous construisez encore les fondamentaux, passez d'abord du temps dans un home lab et sur la PortSwigger Web Security Academy. Les deux vous permettent de vous entraîner sur les stacks ci-dessus sans aucun risque juridique.

3. Filtre 3 : densité de chasseurs (évitez la foule)

Trouvez des programmes où la concurrence est faible mais le scope réel. Évitez la ruée sur les programmes populaires. Cherchez des programmes de divulgation de vulnérabilités avec de courtes listes de Hall of Fame, et des programmes récents qui n'ont pas encore été ratissés.

Pourquoi la densité est un multiplicateur caché

Une forte densité de chasseurs signifie de faibles chances. Quand cinq mille chasseurs regardent la même cible, votre probabilité de trouver un nouveau bug tombe presque à zéro. Les bugs faciles ont été trouvés dès le premier jour. Les bugs moyens ont été trouvés dès la première semaine. Ce qui reste demande une expertise pointue ou des conditions très spécifiques.

Les programmes populaires des grandes plateformes sont comme des coins de pêche bondés. Tout le monde lance sa ligne, et les grosses prises sont rares. Sur les programmes les plus saturés, une large part des rapports entrants sont fermés en doublons, ce qui signifie que même une trouvaille valide peut ne rien vous rapporter.

Les programmes cachés sont votre arme secrète. Certaines des meilleures cibles pour débutants ne sont pas en première page de HackerOne ou Bugcrowd. Ce sont des programmes de divulgation responsable enfouis dans la page sécurité d'une entreprise, ou auto-hébergés via un fichier security.txt sur le site de l'entreprise. Ces programmes ne paient peut-être pas en argent, mais ils offrent des entrées au Hall of Fame, des goodies, de la réputation et de l'expérience. Surtout, ils ont très peu de concurrence. Une entreprise faisant tourner un VDP via son propre site n'a peut-être que cinq ou dix chasseurs qui lui ont déjà remonté quelque chose. Comparez cela à un programme phare avec cinq mille chasseurs. Où préféreriez-vous passer vos deux semaines ?

Cas réel : douze noms au Hall of Fame

Un chasseur a décroché sa première prime de 1 000 $ en évitant complètement la foule. Au lieu de sauter sur un programme populaire, il a choisi un programme public mature et, après près de deux mois, a relu ses notes et revérifié le robots.txt. Il a trouvé un chemin interdit pointant vers un panneau d'administration qui renvoyait un 403, ce qui confirmait l'existence de la ressource, puis a trouvé un moyen de contourner la restriction. Le détail clé est qu'il a choisi une cible ciblée et à faible concurrence, ce qui lui a permis de passer du temps sur des détails comme le robots.txt sans craindre que cinq cents autres chasseurs les aient déjà vérifiés : My First Bug Bounty: How I Earned $1,000.

Un autre chercheur a trouvé un VDP de fintech avec exactement douze noms au Hall of Fame et un scope de seulement deux API. La concurrence étant si faible, il a testé chaque fonctionnalité en profondeur pendant deux semaines et a trouvé trois bugs valides dans des fonctionnalités secondaires que d'autres chasseurs avaient ignorées. Sur un programme avec cinq cents chasseurs actifs, ces bugs auraient disparu dès la première semaine.

Comment mesurer la densité de chasseurs

1. Vérifiez la page Hall of Fame. Si elle compte plus de 200 noms, le programme est saturé. De dix à cinquante noms, vous avez de la marge pour travailler.
2. Regardez l'âge du programme. Un programme lancé il y a six mois avec trois cents rapports résolus est probablement ratissé. Un programme lancé il y a trois semaines avec cinq rapports est neuf.
3. Vérifiez la dernière activité. Si le dernier rapport résolu date d'hier, des chasseurs y travaillent activement. Si le dernier rapport date de trois semaines, les chasseurs sont passés à autre chose, mais les bugs peuvent encore être là.

Trouver les programmes cachés avec les Google dorks

Le Google dorking utilise des opérateurs de recherche avancés pour faire remonter des programmes à faible concurrence :

site:com inurl:responsible-disclosure
site:de inurl:security.txt
inurl:.well-known/security.txt "contact"
site:io "report a vulnerability"

Quand vous trouvez un fichier security.txt (standardisé sous le nom de RFC 9116), lisez-le attentivement. S'il liste un contact et une page de remerciements, vous avez trouvé une cible à concurrence quasi nulle.

4. Déroulez une checklist de recon de 2 heures avant de tester

Une fois qu'une cible passe les trois filtres, ne commencez pas à tirer des payloads. Consacrez deux heures à une reconnaissance structurée. Si vous ne pouvez pas répondre à ces questions en 120 minutes, la cible est trop complexe ou vos notes ont besoin de travail.

Heure 1 : cartographier la surface d'attaque

Votre objectif lors de la première heure est de comprendre toute la surface d'attaque, pas encore de trouver des bugs.

• Créez deux comptes. Vous avez besoin de deux comptes pour tester les IDOR et autres problèmes de contrôle d'accès.
• Identifiez tous les rôles utilisateurs. Guest, User, Admin, Vendor. L'un peut-il passer à un autre ?
• Listez chaque fonctionnalité. Connexion, réinitialisation de mot de passe, mise à jour de profil, upload de fichiers, partage, paiement.
• Trouvez la documentation de l'API. Cherchez des collections Swagger ou Postman, ou lisez les appels JavaScript du frontend.

Heure 2 : sonder les fruits faciles à cueillir

• Flux de réinitialisation de mot de passe. Le token est-il prévisible ? Pouvez-vous le brute-forcer ?
• Upload de fichiers. Y a-t-il un filtrage des extensions ? Pouvez-vous uploader du HTML ou du JavaScript ?
• Mise à jour de profil. Pouvez-vous changer votre e-mail pour celui d'un utilisateur existant ?
• Flux de partage ou d'invitation. Pouvez-vous vous inviter sur la ressource d'un autre utilisateur ?
• Flux de paiement ou de règlement. Le prix final est-il envoyé depuis le client ?

Si vous terminez cette checklist sans rien trouver, n'abandonnez pas. Vous n'avez testé que la surface. Mais si vous trouvez ne serait-ce qu'un comportement bizarre, comme un 200 OK sur un ID modifié ou une limite de débit manquante, vous tenez une piste. Suivez cette piste. Nouveau dans l'outillage de recon ? Commencez par notre tutoriel Nmap et les commandes Linux essentielles.

5. Notez chaque cible avec la grille d'évaluation

Utilisez cette grille pour chaque cible avant d'y consacrer une seule heure. Cela prend cinq minutes et vous évitera des semaines d'efforts gaspillés.

Guide de notation :

• 25 à 30 : cible de premier choix. Engagez quatre semaines.
• 18 à 24 : acceptable. Bon pour apprendre, mais gérez vos attentes.
• En dessous de 18 : laissez tomber. Trouvez mieux. Votre temps est trop précieux.

Gardez cette grille dans vos notes et déroulez-la avant chaque nouvelle cible.

6. Engagez-vous sur une seule cible pendant quatre semaines

Une fois qu'une cible passe les filtres et franchit la grille d'évaluation, engagez-vous dessus pendant quatre semaines. N'ajoutez pas de seconde cible avant d'avoir passé quatre semaines complètes sur la première.

La plupart des débutants sont des touristes de cibles. Ils chassent un programme pendant trois jours, ne trouvent rien et passent au suivant. Ils ne développent jamais la compréhension profonde nécessaire pour trouver les failles de logique. Et les bugs de logique ne se révèlent pas le troisième jour. Ils se révèlent le dixième jour, quand vous remarquez que l'endpoint de suppression de compte se comporte différemment si vous l'appelez deux fois. Ils se révèlent le vingtième jour, quand vous réalisez que l'API mobile a un paramètre que l'application web n'utilise jamais. Ils se révèlent le trentième jour, quand vous comprenez le flux métier mieux que le développeur.

Cette discipline est inconfortable. Elle donne l'impression d'être lente. Mais c'est ainsi que vous construisez la reconnaissance de schémas qui rendra la chasse presque sans effort plus tard. Si vous ne trouvez aucun bug en quatre semaines, relisez vos notes avant de passer à autre chose. Avez-vous manqué une fonctionnalité ? Avez-vous sauté un flux ? Ce n'est qu'ensuite que vous envisagerez de changer.

7. Où le bug bounty s'inscrit dans votre carrière plus large

Le bug bounty est l'un des moyens les plus rapides de prouver publiquement vos compétences en sécurité offensive, mais il est rarement toute l'histoire. La même discipline de choix de cible (focus, profondeur et patience) est ce que recherchent les employeurs chez les testeurs d'intrusion et les red teamers. Si vous construisez une carrière, associez votre chasse à un apprentissage structuré : un parcours de carrière en cybersécurité clair, les bonnes certifications pour débutants, et la preuve que vous savez travailler en toute sécurité, que vous construisez dans un home lab de cybersécurité. Vous changez de domaine sans formation initiale ? Découvrez comment les gens percent sans diplôme.

Lisez des rapports divulgués chaque semaine pour entraîner votre reconnaissance de schémas. La PortSwigger Web Security Academy et les pages projet de l'OWASP sont gratuites, font autorité et correspondent directement aux bugs que vous chasserez.

Conclusion : mettez les chances de votre côté

Le bug bounty n'est pas une loterie. Il s'agit de mettre les chances de votre côté.

Vous n'avez pas besoin de hacker Google pour être un vrai hacker. Vous avez besoin de trouver une cible adaptée à vos compétences actuelles, de la comprendre en profondeur et de chasser là où les autres ne regardent pas. Le système des 3 filtres transforme les suppositions au hasard en un processus. La taille du scope vous garde concentré. La stack technique vous garde efficace. La densité de chasseurs vous garde compétitif.

Votre première entrée au Hall of Fame se cache dans une API ciblée, sur un programme avec douze autres chasseurs, dans un flux de logique métier que personne d'autre n'a pensé à tester. Utilisez les filtres. Utilisez la grille. Engagez quatre semaines. Allez la trouver.