Effective Bug Bounty Reporting
Tips for an effective bug bounty write-up from ToxSec
0x0 Introduction — Reporting as a Skill
In bug bounty, finding the bug is only half the job. The report is the other half — and it’s the part that actually gets you paid.
A raw payload or Burp log won’t cut it. Programs triage hundreds of reports a week. If yours isn’t clear, reproducible, and framed in terms of business impact, it’ll die as “informational” even if the bug is real.
Strong reporting is a skill of its own. It can turn a mid-tier finding into a high payout by showing exactly how it affects users and the business. Weak reporting does the opposite: even a critical bug can be dismissed if the report looks sloppy.
Hunters who want to operate at the top tier treat reporting as part of the exploit chain. The same precision you bring to reconnaissance and payloads should carry into the write-up. Because in bug bounty, the report is the deliverable — it’s the difference between noise and reward.
0x1 Structuring the Report
A good report has a rhythm. Triagers don’t want walls of text, and they don’t want tool dumps. They want a clean, repeatable story: what you found, how you found it, why it matters.
A reliable structure looks like this:
Summary — the one-line headline. Lead with impact, not tools.
“OAuth redirect chain to full account takeover.”
Not: “I ran ffuf and found an open redirect.”
Technical Details — step-by-step with requests, parameters, or code snippets. Enough for anyone on the security team to reproduce.
Impact — the business risk. User data exposure, account takeover, payment fraud, brand trust damage.
Proof of Concept (PoC) — minimal but effective. One script, one curl command, or a short sequence of screenshots.
Recommendations — not always required, but programs appreciate them. Keep it high-level and actionable.
Example Report Snippet
# Open Redirect Chain to Account Takeover
## Summary
Critical vulnerability allowing account takeover through
chained OAuth redirect manipulation.
## Technical Details
GET /oauth/authorize?client_id=mobile_app&redirect_uri=https://target.com.evil.com/callback
Validation bypass:
allowedDomains.includes(url.hostname) // bypassed with subdomain trick
## Impact
Redirect token → attacker domain → OAuth credentials captured → full account takeover.
The structure makes the difference. A triager can skim this in under a minute, understand what’s broken, and move it toward payout.
0x2 Documenting the Attack Flow
Think of your report as a replay button. A triager should be able to walk through your steps exactly as you did, without guessing. If they can’t reproduce it, you won’t get paid.
What to Include
Requests and responses. Show the vulnerable request in full, and the response that proves impact.
Screenshots. Before and after shots tell the story better than text alone.
Annotations. Highlight the parameter, token, or value that makes the bug possible.
Example Flow (OAuth redirect bypass)
Initial request:
GET /oauth/authorize
?client_id=mobile_app
&redirect_uri=https://target.com.evil.com/callback
Validation check bypassed:
allowedDomains.includes(url.hostname)
// accepted attacker domain via crafted subdomain
Impact: redirect leaks the OAuth code → attacker controls victim’s session.
Rule of Thumb
If a junior analyst gets handed your report at 2 AM, can they reproduce the bug without reaching out to you? If not, tighten your documentation.
Clear attack flow doesn’t just make triage easier — it maximizes the payout by proving you understand the vulnerability from start to finish.
0x3 Demonstrating Business Impact
Technical proof is necessary, but it’s not what programs pay for. They pay for reduced risk. That means your report has to connect the bug to a real-world business problem.
The Difference in Framing
Weak: “Found an open redirect.”
Strong: “Open redirect in OAuth flow lets attacker capture tokens and take over accounts.”
That shift in framing can be worth thousands.
How to Show Impact
Map it to users: What can an attacker do to a customer? View their data? Take over their account?
Map it to business: What’s the fallout? Fraud, data leaks, brand trust, regulatory issues?
Show the chain: Don’t stop at step one. Link smaller issues together into a bigger exploit.
Example: Open Redirect → Account Takeover
Redirect parameter not validated.
Attacker captures OAuth token.
Token grants access to user account.
Account access leads to exposed payment data.
The bug started as a redirect. The impact is account compromise and financial risk. That’s what programs reward.
Rule
Always answer the three impact questions:
Who can exploit this?
What do they gain?
Why should the company care?
0x4 Clean Proof of Concept (PoC)
A PoC isn’t about showing off your exploit skills — it’s about proving control in the simplest, cleanest way possible. Triagers don’t want to run a Metasploit module or sift through a 300-line script. They want one clear action that shows the bug is real.
What Makes a Good PoC
Minimal: no weaponization, no payload bloat. Just enough to demonstrate.
Reusable: a single curl command, or a short script that runs out of the box.
Clean: professional formatting, comments, and clear output.
Example PoC (OAuth takeover)
#!/usr/bin/env python3
"""
Open Redirect to Account Takeover PoC
Target: target.com
Author: hunter
"""
import requests
TARGET = "https://target.com"
CALLBACK = "https://attacker.com/callback"
def demonstrate_vulnerability():
params = {
"client_id": "mobile_app",
"redirect_uri": f"https://target.com@{CALLBACK}",
"response_type": "code"
}
r = requests.get(f"{TARGET}/oauth/authorize", params=params)
return f"Executed: {r.url}"
if __name__ == "__main__":
print(demonstrate_vulnerability())
Visual Proof
Screenshot 1: vulnerable request in Burp.
Screenshot 2: attacker domain receiving token.
That’s enough. Nothing flashy, nothing risky — just a clean demonstration that leaves no room for doubt.
0x5 Handling Pushback and Triage
Even with a solid report, you’ll run into resistance. Triagers reject or downgrade findings all the time. The difference between losing the bounty and saving it often comes down to how you handle the pushback.
Common Responses
“Not reproducible.”
“Informational.”
“Out of scope.”
How to Respond
Not reproducible: tighten your steps. Provide full requests, responses, and screenshots. If tokens or sessions expire quickly, note that in the report.
Informational: restate the business impact. If they see only “open redirect,” spell out the token theft chain.
Out of scope: point to the program’s scope definition and explain why the asset or vector is in-bounds.
Professionalism Matters
Don’t argue, don’t spam, don’t get defensive. The best hunters handle pushback by providing evidence, not emotion. Programs notice — and reputation matters. A researcher who consistently submits clear, professional reports gets faster triage and better payouts over time.
0x6 Final Thoughts — Reputation is Currency
Finding vulnerabilities gets you noticed. Writing strong reports gets you paid. In bug bounty, the write-up is as critical as the exploit itself.
Hunters who climb to the top tiers all share the same reporting habits: structured write-ups, clean PoCs, clear impact, and professional handling of triage. Over time, that consistency builds reputation — and reputation is the real currency of bug bounty.
Strong reports get you private invites, higher payouts, and trust from programs. Weak reports pile up in the “informational” bin.
Treat the report as part of the exploit chain. The better you communicate the risk, the more value you create. And in bug bounty, value is what gets rewarded.