Writing a good report

The report is your product: no matter how good the bug, if the team can’t understand or reproduce it, you don’t get paid. A clear, reproducible report with a well-argued impact speeds up triage, maximizes the reward, and builds your reputation.

Structure of a good report

Title        clear and specific ("IDOR in /api/users/{id} lets you read other users' data")
Summary      what it is, where, and the IMPACT in one sentence (for triage)
Steps        NUMBERED, exact reproduction (requests, accounts, values)
PoC          reproducible proof of concept (screenshots, request/response, video if it helps)
Impact       what an attacker gets and why it matters to the BUSINESS
Severity     CVSS + reasoning; align with the program's taxonomy (VRT)
Remediation  how to fix it (shows you understand the bug)

Reproducibility (the #1 thing)

- EXACT steps: URLs, methods, headers, bodies, accounts used (A and B for IDOR)
- concrete values, not "change the id to another" -> "change 1337 to 1338"
- environment/preconditions (logged in as X, feature enabled)
- if the triager can't reproduce it in 2 minutes, it slows down or gets closed

Arguing impact and severity

- translate the bug to BUSINESS RISK: "access to all users' data" > "IDOR"
- CVSS as a common language, but explain the vector; don't inflate (you lose credibility)
- demonstrate the realistic WORST case (not an impossible theoretical one): chain if it raises impact
- align with the program's table/VRT (bb-plataformas)

Chaining bugs

- several low-severity bugs chained can be CRITICAL (e.g. info leak + IDOR + CSRF)
- report the CHAIN with the final impact, making each link clear
- this is the best-paid and what sets you apart

Communication and triage

- professional, respectful tone; the triager is your ally, not your rival
- respond quickly to questions; provide more PoC if asked
- if you disagree on severity/duplicate, argue with DATA, without being rude
- don't disclose publicly without permission (breaking disclosure = ban)

Blue Team / note

A report is worth its reproducibility: exact steps > vague prose.
Translating the bug to business risk maximizes severity and reward.
Chaining low-impact bugs into a critical one is the biggest differentiator.
Professional communication: the triager is an ally; no disclosure without permission.

Best practices and common mistakes

Make the bug reproducible: exact steps, minimal PoC, clear impact; a confusing report gets rejected even if valid.
Explain the business impact, not just the technical vuln; justify a higher severity (and payout) that way.
Common mistake: inflating severity or including real exfiltrated data; demonstrate with a minimal PoC, no harm.

Testing checklist

Clear, specific title with the impact
Summary with what/where/impact in one sentence
Numbered, EXACT reproduction steps
Reproducible PoC (requests/screenshots/video)
Impact translated to business risk
CVSS severity aligned with the program’s VRT
Proposed remediation
Professional communication; no unauthorized disclosure