Bug Reporting Guide

Writing reports that get accepted and paid

Writing Effective Bug Reports

A good report gets triaged faster, paid faster, and makes the program team's life easier. The key is clear reproduction steps and a concrete description of the impact.

Report Structure

Title

"[Vulnerability Type] in [Affected Component/Feature]"

Examples:

  • "Stored XSS in User Profile Comments"
  • "IDOR Allows Access to Other Users' Payment Information"
  • "Authentication Bypass in Password Reset Functionality"

Description

"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]."

Steps to Reproduce

  1. Log in to the application at [URL]
  2. Navigate to [specific page/feature]
  3. Perform [specific action] with [specific input/parameter]
  4. Observe [the vulnerability manifestation]

Impact

"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]."

Proof of Concept (PoC)

  • Screenshots/videos showing the exploitation
  • Sample code or commands used
  • Network request/response pairs

Remediation (Optional)

"This issue could be remediated by [specific fix suggestion]. Additionally, I recommend [broader security control or practice]."

Severity Ratings

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

Proof of Concepts

Show the bug is real without doing any damage. Use your own test accounts, don't access real user data beyond what's needed to prove the point, and don't share findings publicly before the fix is deployed.

Good PoC Formats

  • Screenshots: Best for simple UI issues or visible results of exploitation
  • Videos: Ideal for complex sequences of actions or dynamic issues
  • HTTP Request/Response: For API vulnerabilities or network-level issues
  • Code snippets: For demonstrating payloads or exploitation scripts
  • Network capture files: For complex multi-step network interactions

Common Issues to Avoid

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 Be professional, answer questions quickly, and don't argue about severity

Understanding Bounty Rewards

Each program sets its own bounty ranges - check the program page. Better reports with clear impact tend to get paid at the higher end of the range.

Tools & Resources

Essential Tools

Learning Resources

Find a program to test

Browse public programs and start submitting reports.