GUIDE GRATUIT

Comment trouver ton premier bug en 7 jours

Un plan d'action concret, jour par jour, pour passer de zéro à ton premier rapport de vulnérabilité accepté.

Trouver son premier bug en bug bounty peut sembler intimidant. Trop d'outils, trop de techniques, pas assez de direction. Ce guide te donne un plan précis sur 7 jours pour aller droit au but. Pas de théorie inutile — que de l'action.

1

Jour 1 — Choisir sa plateforme et sa cible

Ne perds pas de temps à comparer. Inscris-toi sur HackerOne ou Bugcrowd (ou YesWeHack si tu préfères le français).

// Critères pour choisir ta première cible

  • Programme ouvert (pas sur invitation)
  • Scope large (wildcard *.example.com)
  • Temps de réponse < 7 jours
  • Programme actif avec des bugs récemment résolus

Astuce : les programmes récemment lancés ont souvent plus de bugs faciles à trouver.

2

Jour 2 — Reconnaissance : cartographier la surface d'attaque

La reconnaissance est la phase la plus importante. C'est là que les bons hunters se démarquent. L'objectif : trouver un maximum de sous-domaines, pages et endpoints.

# Sous-domaines

$ subfinder -d example.com -silent | httpx -silent > live.txt

# Découverte de contenu

$ dirsearch -u https://app.example.com -e php,js,html

# URLs historiques

$ cat live.txt | waybackurls | sort -u > urls.txt

Stocke tout dans des fichiers texte organisés. Tu vas y revenir.

3

Jour 3 — Les low-hanging fruits : ce que tout le monde rate

Avant de chercher des RCE compliqués, cible les vulnérabilités que la majorité des hunters ignorent parce qu'elles semblent "trop simples" :

IDOR

Change les IDs dans les requêtes API pour accéder aux données d'autres utilisateurs

Broken Access Control

Accède à des pages admin ou à des endpoints sans autorisation

Information Disclosure

Fichiers exposés : .env, .git, stack traces, clés API

Open Redirect

Paramètres de redirection non validés (?redirect=, ?next=)

4

Jour 4 — Maîtriser Burp Suite (le minimum vital)

Burp Suite Community (gratuit) suffit largement pour commencer. Concentre-toi sur 3 fonctionnalités :

1.

Proxy + Intercept

Intercepte chaque requête HTTP entre ton navigateur et le serveur. Modifie les paramètres à la volée.

2.

Repeater

Rejoue et modifie des requêtes individuellement. Idéal pour tester les IDOR et les injections.

3.

HTTP History

Parcours tout l'historique des requêtes. Filtre par domaine, méthode, code de réponse. C'est une mine d'or.

5

Jour 5 — Attaquer méthodiquement les endpoints

Navigue sur l'application comme un utilisateur normal pendant 30 minutes, Burp tourne en arrière-plan. Ensuite, passe à l'attaque :

// Checklist d'attaque par endpoint

  • ☐ Tester chaque paramètre avec des valeurs inattendues
  • ☐ Changer les IDs numériques/UUID → IDOR
  • ☐ Supprimer le token d'auth et retenter → Broken Auth
  • ☐ Changer la méthode HTTP (GET→POST, POST→PUT) → Method Override
  • ☐ Ajouter des headers (X-Forwarded-For, X-Original-URL) → Bypass
  • ☐ Tester les injections basiques (' OR 1=1--) dans les inputs
6

Jour 6 — Analyser le JavaScript front-end

Le code JavaScript côté client est une mine d'informations. Les développeurs y laissent souvent des endpoints cachés, des clés API et de la logique métier.

# Extraire les endpoints depuis les fichiers JS

$ cat urls.txt | grep "\.js$" | while read url; do

curl -s "$url" | grep -oP '"/api/[^"]*"'

done | sort -u

Cherche aussi dans les source maps (.js.map) — elles contiennent parfois le code source complet de l'application.

7

Jour 7 — Rédiger et soumettre ton rapport

Tu as trouvé quelque chose ? Même un bug mineur, soumets-le. Un rapport bien rédigé fait toute la différence entre un bug accepté et un "N/A".

// Structure d'un bon rapport

Titre

Clair et descriptif. Ex: "IDOR on /api/users/{id} allows access to other users' profile data"

Description

Ce que tu as trouvé, où, et pourquoi c'est un problème de sécurité.

Steps to Reproduce

Étapes numérotées, reproductibles par quelqu'un qui n'a jamais vu l'app.

Impact

Ce qu'un attaquant pourrait faire concrètement (voler des données, modifier un compte...).

Preuve

Screenshots, requêtes Burp, vidéo. Plus c'est visuel, mieux c'est.

Conseil : écris toujours en anglais, même sur YesWeHack. Ça montre du professionnalisme.

Et après ?

Ce guide te donne les bases. Mais trouver des bugs de manière régulière et rentable, ça demande une méthodologie complète : reconnaissance avancée, exploitation de chaque type de vulnérabilité, automatisation, et rédaction de rapports qui paient.

C'est exactement ce que tu apprends dans la Formation Bug Bounty Complète — 62 leçons vidéo, du concret, et une aide personnalisée sur tes rapports.