Learn how to write effective bug reports that get accepted and rewarded
The quality of your bug report directly impacts how quickly it gets triaged, fixed, and rewarded. A well-written report helps the program team understand the issue efficiently and accurately assess its severity.
A well-structured report makes it easy for program teams to understand and validate your findings. Here's an effective template:
Create a clear, specific title that summarizes the issue:
"[Vulnerability Type] in [Affected Component/Feature]"
Examples:
Provide a concise overview of the vulnerability:
"I discovered a [vulnerability type] in [specific location]. This vulnerability allows an attacker to [describe what an attacker could do] by [brief description of the attack method]."
List the exact steps to replicate the issue:
Explain the real-world consequences:
"This vulnerability allows an attacker to [specific outcome]. The business impact includes [describe how this affects users, data, or the business]. This could lead to [potential worst-case scenario]."
Provide evidence demonstrating the vulnerability:
Suggest potential fixes (optional but appreciated):
"This issue could be remediated by [specific fix suggestion]. Additionally, I recommend [broader security control or practice]."
Suggesting an appropriate severity helps program teams prioritize and value your report. Bugbop uses the following severity levels:
| Severity | Criteria | Examples |
|---|---|---|
| Critical | High impact, easy exploitability, no mitigating factors | Remote code execution, full system compromise, significant data breach |
| High | Significant impact, straightforward exploitation | Authentication bypass, stored XSS with sensitive context, direct access to sensitive data |
| Medium | Moderate impact, may require specific conditions | Reflected XSS, CSRF affecting important functions, limited information disclosure |
| Low | Minor impact, difficult exploitation, significant mitigations in place | Self-XSS, low-risk information leakage, issues requiring unlikely user interaction |
A good proof of concept (PoC) demonstrates the vulnerability clearly while following program rules and ethical guidelines.
Learn from frequent mistakes that can result in report rejection or reduced bounties:
| Common Mistake | Better Approach |
|---|---|
| Submitting duplicate reports without checking existing reports | Search for similar reports before submitting; if unsure, emphasize unique aspects of your finding |
| Reporting issues clearly listed as out-of-scope | Carefully read the program policy; if you think an exception is warranted, explain why this particular finding might deserve reconsideration |
| Submitting low-quality reports with insufficient detail | Review your report before submission; ensure it includes all elements in the recommended structure |
| Overestimating severity without justification | Base severity on actual impact, not theoretical scenarios; provide concrete evidence for your assessment |
| Poor communication or unprofessional responses | Maintain respectful, constructive communication; respond to questions promptly and thoroughly |
Bounties are typically determined by several factors beyond just technical severity:
While amounts vary by program, here are typical ranges you might encounter:
Equip yourself with the right tools and knowledge to find impactful vulnerabilities: