Workflow bug bounty avec Burp Suite : recon → exploit → rapport (2026)

📍 Article principal du cluster : Burp Suite : le guide pratique 2026
Cet article fait partie du cluster « Burp Suite 2026 ». Il s’appuie sur tous les tutoriels précédents — Proxy, Repeater, Intruder, Scanner, JWT, Extensions.

Cadre éthique préalable. Le bug bounty est légal parce que vous opérez dans le scope explicite défini par le programme. Toute exploration hors scope, toute publication d’un finding sans avoir laissé le délai de fix au vendor, toute monétisation alternative d’une vulnérabilité (revente, exploitation), c’est l’infraction et la fin de votre carrière. Lisez intégralement les règles de chaque programme avant de toucher à quoi que ce soit. C’est non négociable.

Le bug bounty est l’un des rares métiers techniques où vous pouvez démarrer en autodidacte, depuis n’importe quelle ville d’Afrique de l’Ouest, sans diplôme ni accréditation, et facturer en USD à des entreprises mondiales. Plusieurs hunters francophones africains figurent dans les leaderboards de HackerOne, Bugcrowd, Intigriti. Ce tutoriel pose la méthodologie pratique : choisir un programme, faire le recon, mapper la cible, identifier les surfaces d’attaque, exploiter, valider, rapporter. Burp Suite est le compagnon constant de ce flux.

Prérequis

• Burp Suite installé, idéalement Pro pour le Scanner.
• Maîtrise des outils : Proxy, Repeater, Intruder, JWT Editor, extensions essentielles.
• Compréhension des classes OWASP Top 10 et de leurs détections.
• Compte sur au moins une plateforme : HackerOne, Bugcrowd, Intigriti, YesWeHack (français, intéressant pour francophones).
• Niveau : intermédiaire à avancé.
• Temps estimé : 90 minutes pour ce tutoriel + plusieurs semaines de pratique.

Étape 1 — Choisir un programme à votre niveau

Erreur classique de débutant : se ruer sur Yahoo, Apple ou PayPal — programmes ultra-mature où des centaines de hunters expérimentés ont déjà fouillé tout. Probabilité de finding : faible. Frustration : élevée.

Stratégie réaliste pour démarrer : ciblez des programmes récents (publiés depuis moins de six mois), avec un scope large (multiples sous-domaines, plusieurs apps), des récompenses modestes mais accessibles (50 à 500 USD pour les premiers tiers de sévérité). Les très gros programmes paient bien sur les findings rares, mais c’est statistiquement après plusieurs années d’expérience.

Sur HackerOne, filtrez les programmes par « Last bounty » récent et « Average bounty » modéré. Lisez la page « Scope » de chaque programme — quels domaines, quelles apps mobiles, quelles APIs. Lisez aussi « Out of scope » avec attention — y compris « DoS, social engineering, brute force ». Lisez la « Vulnerability Disclosure Policy ».

Pour les francophones, YesWeHack a beaucoup de programmes français et européens, communication fluide en français avec les triages. Bon point d’entrée culturel.

Étape 2 — Comprendre le scope avant tout test

Le scope définit ce que vous avez le droit de tester. Lisez-le quatre fois. Notez sur papier les domaines explicitement autorisés. Notez ce qui est explicitement exclu (parfois *.example.com est dans le scope mais internal.example.com est exclu).

Notez aussi les restrictions techniques. Beaucoup de programmes interdisent les scanners automatiques, les attaques DoS (rate limiting violation, fuzzing massif), les tests sur les comptes d’utilisateurs réels (créez un compte de test dédié), les actions destructives (suppression de données, export massif). Le non-respect de ces règles peut faire annuler votre rapport et vous bannir.

Pour les programmes avec scope mobile (apps Android/iOS), vérifiez que le reverse engineering du binaire est autorisé. Ce n’est pas systématique — certains programmes acceptent uniquement le test du backend exposé via le client mobile.

Étape 3 — Recon : cartographier la cible

Avant de lancer Burp, faites le recon. C’est l’étape qui distingue un hunter sérieux d’un script kiddie. Le but : comprendre l’écosystème de la cible avant de tester.

Outils de recon classiques (en complément de Burp). amass et subfinder pour énumérer les sous-domaines. httpx pour vérifier ceux qui sont vivants et leurs technologies. waybackurls pour trouver des URLs historiques (Wayback Machine), utiles pour les endpoints abandonnés mais encore actifs.

subfinder -d example.com -silent | httpx -silent -title -tech-detect -status-code > recon.txt
waybackurls example.com | sort -u >> historical-urls.txt

Le recon prend une à trois heures sur un programme moyen. Vous obtenez : la liste des sous-domaines, les technologies utilisées (frameworks, CMS, langages), les endpoints historiques. Cette cartographie alimente votre plan d’attaque dans Burp.

Pour les hunters qui veulent industrialiser, des outils comme ProjectDiscovery (suite de tools en ligne de commande) ou Nuclei (scanner de templates) automatisent une grande partie du recon. Ils sont open source et gratuits.

Étape 4 — Mapping détaillé dans Burp

Avec le recon en main, ouvrez Burp et démarrez un nouveau projet sur disque dédié à ce programme bug bounty. Configurez le scope strict — uniquement les sous-domaines autorisés. Désactivez le logging hors scope.

Naviguez l’application principale via Firefox + Burp Proxy pendant 30 à 60 minutes. Ne testez rien encore. Vous comprenez. Vous identifiez les fonctions principales : login, signup, profile, search, payment, admin, etc. Vous notez les endpoints API qui transitent en arrière-plan. Vous repérez les paramètres qui semblent intéressants.

L’erreur des débutants est de tester immédiatement. Le pro investit du temps en compréhension. Une heure de cartographie économise dix heures de fuzzing aveugle.

Sur Burp, l’onglet Target → Site map se remplit. Vous pouvez maintenant identifier les zones les plus prometteuses pour le test. Typiquement : les endpoints qui manipulent des identifiants utilisateur (IDOR), les fonctions d’admin (broken access control), les endpoints d’upload (unrestricted file upload, path traversal), les APIs de webhook (SSRF), les zones d’authentification (JWT, OAuth, password reset).

Étape 5 — Stratégie d’attaque par classe de vulnérabilité

Plutôt que tester au hasard, attaquez systématiquement par classe. Pour un premier programme, parcourez ces sept classes dans l’ordre.

1. Broken Access Control / IDOR. Pour chaque endpoint qui prend un identifiant utilisateur, testez l’accès avec une session basse. Autorize automatise grandement. Les findings IDOR paient régulièrement entre 200 et 2000 USD selon l’impact.

2. Authentication issues. Reset password, MFA bypass, JWT defects, OAuth defects, race conditions sur login. Voir le tutoriel JWT et OAuth.

3. Server-Side Injection. SQL injection (Repeater + Scanner), command injection sur uploads ou paramètres mal filtrés, SSTI sur les fonctions d’email/template.

4. Server-Side Request Forgery (SSRF). Toute fonction qui prend une URL en paramètre est candidate : webhooks, fetcher, image proxy, PDF generator. Burp Collaborator est l’outil pour la détection blind SSRF.

5. Cross-Site Scripting (XSS). Reflected, stored, DOM-based. Le Scanner Pro et l’extension Reflected Parameters identifient les points d’injection candidats. Validation manuelle indispensable.

6. Information Disclosure. Logs exposés, fichiers de config (.env, .git/config), debug endpoints. Le directory bruteforce avec des outils comme ffuf ou Burp Intruder sur des wordlists discovery est l’arme.

7. Business Logic. La classe la plus rémunératrice mais la plus difficile. Bugs spécifiques à la logique métier — race conditions sur transferts d’argent, abus de coupons, contournements de paywalls, double-spending. Demande de l’imagination métier en plus de la technique.

Étape 6 — Workflow exploit : du finding à la PoC reproductible

Quand vous identifiez un comportement suspect, basculez en mode exploit. Étape 1 : reproduire le bug avec une séquence minimale de requêtes. Plus c’est court, plus c’est convainquant. Étape 2 : confirmer l’impact réel. Pouvez-vous lire des données d’autres utilisateurs ? Pouvez-vous modifier ? Pouvez-vous escalader vers admin ?

Étape 3 : documenter avec capture Burp. Onglet Repeater où vous reproduisez, capturez la requête malicieuse et la réponse qui prouve l’impact. Pour les bugs en plusieurs étapes, capturez chaque étape. La présentation visuelle du PoC dans Burp est plus convaincante qu’une description textuelle.

Étape 4 : tester la portée. Si l’IDOR marche sur user_id 1, marche-t-il sur 2, 3, 100 ? Si oui, vous avez un IDOR généralisé — finding de niveau Critical. Si seulement sur certains IDs, peut-être que vous avez un cas particulier — niveau plus bas.

Étape 7 — Rédiger un rapport bug bounty efficace

Le rapport est ce qui détermine si vous êtes payé et combien. Structure standard à respecter rigoureusement.

Title. Une phrase qui décrit le bug et l’impact en quinze mots maximum. « Account takeover via JWT alg=none on /api/auth/refresh » est bon. « Found a JWT issue » est mauvais.

Summary. Trois ou quatre phrases qui décrivent la vulnérabilité, le composant affecté, et l’impact métier. Ce que le triage lit en premier.

Steps to Reproduce. Liste numérotée précise. Chaque étape commence par une action claire. Commandes curl ou capture Burp en annexe pour rejouer. Si le triage ne peut pas reproduire en cinq minutes, le rapport est perdu.

Impact. Décrivez l’impact en termes business : « un attaquant peut prendre le contrôle de n’importe quel compte utilisateur sans interaction de la victime ». Évitez le jargon pur. Liez à OWASP, CWE, CVSS scoring si pertinent.

Remediation. Une suggestion concrète de fix. Pas un remède générique « valider les entrées » — quelque chose de précis. « Configurer la lib JWT pour rejeter explicitement alg=none ; ne whitelister que HS256 et RS256 ».

Annexes. Capture vidéo (asciinema ou GIF) si le bug est complexe ; sinon screenshots Burp suffisent. Lien vers le PoC en environnement live si autorisé par le programme.

Étape 8 — Soumettre et gérer le triage

Soumettez sur la plateforme. Le triage prend généralement 1 à 14 jours selon la maturité du programme. Trois issues possibles : Triaged (validé, en attente de fix par le vendor), Duplicate (quelqu’un a soumis le même bug avant — pas de paiement), Not applicable (le triage estime que ce n’est pas un bug, ou hors scope).

Si « Duplicate », vérifiez que la duplication est réelle (parfois le triage assimile des bugs à tort). Vous pouvez argumenter poliment. Si « Not applicable », demandez clarification — parfois l’argumentation revaloriase. Si « Triaged », attendez. Le bounty arrive après le fix, ce qui peut prendre des semaines à des mois.

Pendant l’attente, ne testez plus le même endpoint — risque de casser le fix en cours, ou d’apparaître insistant. Passez à un autre programme.

Étape 9 — Construire sa réputation et son revenu

Le bug bounty est un marathon. Le premier mois, vous gagnerez peut-être rien. Le deuxième, un petit bug à 100 USD. Le troisième, votre premier critical à 1500 USD. La courbe est exponentielle pour qui persévère et apprend de chaque rapport.

Pour accélérer la courbe : spécialisez-vous. Plutôt que faire un peu de tout, devenez excellent sur une classe — par exemple expert OAuth/SAML, ou expert race conditions, ou expert cache poisoning. Vous trouvez plus vite des bugs dans votre niche, et certains programmes vous invitent en privé pour exploiter votre spécialité.

Tenez un journal de bord. Pour chaque programme touché, notez ce que vous avez exploré, les hypothèses formulées, ce qui a marché, ce qui n’a pas. À six mois, vous avez une base de connaissances personnelle qui vaut de l’or.

Suivez les disclosures publiques (HackerOne hacktivity, public reports) — c’est l’école continue du métier. Chaque rapport public est une étude de cas gratuite.

Étape 10 — Vérifier votre maîtrise par votre premier rapport

Pour valider, l’exercice est simple : trouver et soumettre votre premier finding sur un vrai programme. Pas un lab. Pas un CTF. Un programme bug bounty actif, avec un vrai vendor.

Choisissez un programme jeune avec scope large. Allouez deux à trois jours de travail. Suivez la méthodologie de ce tutoriel. Si vous trouvez un IDOR, un broken access control, ou un info disclosure, soumettez. Même si c’est « Low » et paye 50 USD — vous avez votre premier rapport accepté, et le déclic mental est fait.

Si après deux semaines de pratique sérieuse vous n’avez rien trouvé, c’est normal. Beaucoup commencent par six mois sans bounty. La persévérance est le facteur principal de succès dans ce métier.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour un hunter basé à Dakar, Abidjan, Lomé ou ailleurs en Afrique de l’Ouest, le bug bounty est l’un des meilleurs métiers tech. Pas de prérequis géographique, pas de visa nécessaire, paiement en USD via PayPal, Wise, Payoneer ou virement international. Plusieurs hunters ouest-africains gagnent l’équivalent d’un cadre supérieur local sur leurs primes.

Quelques points pratiques. Premièrement, la connectivité. Pour des sessions Burp longues sur des cibles internationales, la 4G stable suffit, mais investissez dans une bonne fibre quand vous passez en mode pro — la latence et les déconnexions tuent la productivité. Deuxièmement, le fuseau horaire. Les triages des grands programmes (HackerOne, Bugcrowd) sont basés en Amérique ou en Europe. Vos rapports soumis le soir Dakar arrivent le matin US — bon timing pour un retour rapide.

Troisièmement, les moyens de paiement. PayPal accepte les comptes africains pour réception, mais pas tous les pays peuvent retirer facilement. Wise (anciennement TransferWise) marche bien pour la plupart des pays UEMOA. Payoneer fonctionne aussi. Pour la conversion en FCFA, votre banque locale ou Wave / Orange Money font le job. Anticipez la fiscalité : déclarez vos revenus, certains pays ont des conventions fiscales qui simplifient.

Quatrièmement, la communauté. Plusieurs Discord et Telegram francophones rassemblent des hunters africains. Rejoindre une de ces communautés accélère l’apprentissage — partage de tips, écoute des erreurs des autres, bouchées de mentorat informel. Cherchez « bug bounty francophone » sur Discord.

Tutoriels frères

• Repeater pas-à-pas — l’outil principal en exploit.
• Extensions BApp essentielles — votre arsenal pour le bug bounty.
• Burp + JWT et OAuth — classes très rémunératrices.

Pour aller plus loin

• 🔝 Retour au pilier : Burp Suite : le guide pratique 2026
• HackerOne : hackerone.com
• Bugcrowd : bugcrowd.com
• Intigriti : intigriti.com
• YesWeHack : yeswehack.com
• HackerOne Hacktivity (rapports publics) : hackerone.com/hacktivity

FAQ

Combien gagne un bug bounty hunter ?
Très variable. Pour un débutant : 0 à quelques centaines de dollars par mois pendant six mois. Pour un intermédiaire après un an de pratique régulière : 1000 à 5000 USD/mois. Pour les top hunters mondiaux : 100 000 à 1 000 000 USD/an. La courbe est exponentielle pour qui persévère.

Faut-il une formation officielle pour démarrer ?
Non. La PortSwigger Web Security Academy + pratique sur des programmes jeunes suffit. Beaucoup de top hunters sont autodidactes. Une certification (OSCP, OSWE) aide pour le réseau professionnel mais n’est pas requise.

Le bug bounty en français existe-t-il ?
Oui, surtout via YesWeHack, plateforme française. La communication avec les triages se fait en français. Quelques programmes français significatifs (banques, e-commerce, startups). Bon point d’entrée pour les francophones.

Que faire si on me bannit d’une plateforme ?
Lisez la communication officielle, comprenez la raison. Si c’est un test hors scope, c’est légitime — apprenez et passez à autre chose. Si c’est un malentendu, faites appel poliment. Le karma compte sur ces plateformes.

Puis-je publier mes findings sur mon blog ?
Seulement après autorisation explicite du vendor (parfois automatique passé un délai, parfois sur demande). Publier avant fix peut violer la disclosure policy et vous coûter votre compte. Toujours attendre le feu vert.

Mots-clés secondaires : bug bounty workflow, HackerOne, Bugcrowd, Intigriti, YesWeHack, recon, PoC, rapport bug bounty.