Méthodologie Bb
/SKILLÀ utiliser au DÉBUT de toute session de chasse aux failles, lorsque vous changez de cible ou lorsque vous ne savez plus trop quoi faire ensuite.
name: bb-methodology
description: Use at the START of any bug bounty hunting session, when switching targets, or when feeling lost about what to do next. Master orchestrator that combines the 5-phase non-linear hunting workflow with the critical thinking framework (developer psychology, anomaly detection, What-If experiments). Routes to all other skills based on current hunting phase. Also use when asking "what should I do next" or "where am I in the process."
Bug Bounty Methodology: Workflow + Mindset
Master orchestrator for hunting sessions. Combines the 5-phase non-linear workflow with the critical thinking framework that separates top 1% hunters from the rest.
PART 0: MODE CONFIRMATION (Before Anything Else)
Confirm the engagement type before deciding what counts as a finding. The same target produces a different report shape depending on which mode applies. Getting this wrong is the single biggest waste of time in this workflow — answer it explicitly before Phase 0.
| Engagement type | What counts as a finding | What gets rejected |
|---|---|---|
| Bug bounty (H1 / Bugcrowd / Intigriti / private VDP) | Impact-demonstrated bugs ONLY. Full chain to attacker-attainable harm. | Hygiene (EoL software alone, permissive CSP alone, stack traces, info disclosure without concrete impact, "best practice" violations) |
| Red team (external client engagement) | Hygiene findings + recon + IoCs + defensive-state observations are ALL deliverables | Nothing — even "no finding here" is reportable as a positive defensive observation |
| Pentest (signed SoW / WAPT) | Depends on SoW. Read scope explicitly. Usually accepts hygiene + impact + recon | Out-of-scope assets, unsigned testing |
| Internal audit | Compliance-mapped findings (PCI / ISO / NIST / DPDPA / GDPR) | Findings without a control-mapping |
Hard rule: Before Phase 0 runs, write the engagement type as the first line in your hunt notes. If you can't answer it from the user's instruction, ASK once. Don't assume — the mistake costs both you and the triager.
Lesson from an authorized engagement: First-pass on this target produced 5 hygiene findings (SP2013 EoL, permissive CSP, stack traces) shipped in red-team format. The engagement was bug-bounty. Findings would have been N/A'd as "informational, no impact demonstrated." After the corrected pass with hygiene-as-context-not-finding, the same target yielded 11 impact-demonstrated bugs including 3 Critical.
PART 1: MINDSET (How to Think)
Core Principle
Hunting is not "find a bug" -- it is "prove an attack scenario." Think like an attacker with a specific goal, not a scanner looking for patterns.
Daily Discipline: Define, Select, Execute
Before touching any tool:
- Define: "Today I target [feature/domain] to achieve [CIA impact]"
- Select: Choose 1-2 vuln classes (IDOR, Race Condition, etc.)
- Execute: Focus ONLY on selected techniques. No wandering.
5 Ultimate Goals (Pick One Per Session)
- Confidentiality -- steal data the attacker shouldn't see
- Integrity -- modify data the attacker shouldn't change
- Availability -- disrupt service (app-level DoS only)
- Account Takeover -- control another user's account
- RCE -- execute commands on the server
4 Thinking Domains
#### 1. Critical Thinking (deep analysis)
Question trust boundaries:
- Frontend control disabled? Send request directly via proxy
user_role=usercookie? Change toadminprice=1000in POST? Change to1<script>blocked? Try<img onerror=...>
Reverse-engineer developer psychology:
- Feature A has auth checks -> Similar feature B (newly added) probably doesn't
- Complex flows (coupon + points + refund) -> Edge cases have bugs
/api/v2/userexists -> Does/api/v1/userstill work with weaker auth?
What-If experiments:
- Skip checkout -> hit
/checkout/successdirectly - Skip 2FA -> navigate to
/dashboard - Send coupon request 10x simultaneously -> Race condition?
- Replace
guid=f8a2...withid=100on sibling endpoint -> IDOR?
#### 2. Multi-Perspective (multiple angles)
| Perspective | What to check |
|---|---|
| Horizontal (same role) | User A's token + User B's ID -> IDOR |
| Vertical (different role) | Regular user -> /admin/deleteUser |
| Data flow (proxy view) | Hidden params in JSON: debug=false, discount_rate |
| Time/State | Race conditions, post-delete session reuse |
| Client environment | Mobile UA -> legacy API with weaker auth |
| Business impact | "What's the $ damage if this breaks?" |
#### 3. Tactical Thinking (pattern detection)
- Naming anomaly:
userIdeverywhere but suddenlyuser_id-> different dev, weaker security - Error diff: Same 403 but different JSON structure -> different backend systems
- Environment diff: Prod vs Dev/Staging -> debug headers, CSP disabled
- Version diff: JS file before/after update -> new endpoin