BBRecon Methodology

Real-world Bug Bounty methodology — built from actual program experience, not theory.

Everything here comes from working live programs: what worked, what got marked N/A, why, and how to tell the difference before you submit.

Companion tool: BurpRecon

---

Index

#	Topic	Key question answered
01	Recon & Burp XML Analysis	How to process 1500+ requests in under 5 minutes
02	IDOR / BOLA Scoring	When is a numeric ID actually exploitable?
03	Auth Flows & JWT Attacks	Host Header Injection: real vs false positive
04	WAF / CDN Detection	Why Python gets 403 and Burp Repeater doesn't
05	Open Redirect Validity	When does a redirect param actually matter?
06	Reporting & Triage	How to write a report that doesn't get closed as N/A

---

Core Principles

1. No PoC = No report. If you can't reproduce it step by step, don't submit it. Triage will close it and your signal score drops.

2. Impact drives severity, not technique. An IDOR on /api/users/{id}/preferences is different from one on /api/users/{id}/bank-accounts. Same pattern, completely different severity.

3. Understand why the control exists. A 403 on an IDOR candidate isn't a dead end — it's a signal that the ACL is implemented server-side. Test with a second authenticated session from a different account before giving up.

4. WAFs are not security. Akamai, Cloudflare, and F5 blocking your Python script doesn't mean the endpoint is protected. It means the transport is protected. The vulnerability may still exist — test via Burp Repeater.

5. False positives waste everyone's time. One N/A report hurts your reputation more than five valid reports help it. This methodology is about ruling things out as fast as finding them.

---

Quick Decision Trees

Is this IDOR worth testing?

Numeric ID in path?
├── No  → not IDOR (check UUID/entropy section)
└── Yes → What is the HTTP method & status code?
    ├── GET + 200                          → CRITICAL — test immediately with second session
    ├── POST/PUT/PATCH/DELETE + 2xx/201/204 → HIGH — write/delete on other user's data
    ├── GET + other 2xx                    → MEDIUM — unclear impact, confirm data ownership
    └── 4xx?
        ├── 403 → ACL enforced, skip unless you have role escalation
        └── 404 → ID is the object key → POTENTIAL, test with second session

Is this Host Header Injection valid?

Endpoint sends emails? (reset, OTP, invite, verify)
├── No  → not exploitable via HHI (no email poisoning possible)
└── Yes → Does it use Host header to build the link in the email?
    ├── No  → FP — the URL is hardcoded server-side
    └── Yes → Is there a cache in front? (Via, X-Cache, CF-Cache)
        ├── No  → Password Reset Poisoning only (still High)
        └── Yes → Web Cache Poisoning possible → Critical

Is this Open Redirect valid?

Does the redirect param control where the browser goes?
├── No (reflected but not followed) → FP
└── Yes → Does it escape the origin domain?
    ├── No (same domain only) → Low/Info
    └── Yes → Is it used post-auth? (login?next=, OAuth redirect_uri)
        ├── Yes → High (token/session theft possible)
        └── No  → Medium (phishing vector)