Actionable Bug Bounty Reports: Evidence & Steps
A bug bounty report is actionable when it gives a reviewer enough verified evidence to confirm the vulnerability and exact reproduction steps to trigger it reliably. This guide breaks down what that evidence looks like, how to structure reproduction steps, and why vague reports get closed as informative.
Background: Why Most Reports Fail
Bug bounty programs receive thousands of submissions, and triage teams have limited time. A report that says “I found an XSS on your site” without a proof-of-concept or a URL is almost always rejected. The core problem is ambiguity: a reviewer cannot verify what they cannot see. Actionable reports remove guesswork by providing a clear chain from description to demonstration.
Programs like HackerOne and Bugcrowd publish guidelines that emphasize reproducibility. A report is considered actionable if a different researcher (or the triage team) can follow the steps and observe the same result. This standard is not about writing more words; it is about writing the right details in the right order.
What Makes Evidence Actionable
Evidence is the proof that the vulnerability exists and that it has real impact. The most effective evidence includes:
- Proof of Concept (PoC): A minimal working example, often a URL, a script, or a request that triggers the bug.
- Screenshots or screen recordings: Visual proof of the outcome, especially for UI-based issues like stored XSS or broken access control.
- HTTP request/response pairs: Exact requests (method, path, headers, body) and the server’s response, which let a reviewer replay the attack.
- Impact statement: A clear explanation of what an attacker can do, such as stealing session tokens, modifying data, or escalating privileges.
A common mistake is to include only a screenshot without the underlying request. A reviewer cannot copy a screenshot into a tool, but they can copy a raw HTTP request. Always include both when possible.
How to Write Reproduction Steps
Reproduction steps are a numbered list that a reviewer can follow from a clean state. They should be specific and sequential. Here is a template that works for most web vulnerabilities:
- Set up the environment (e.g., “Log in as a standard user on the staging server”).
- Navigate to the exact page or endpoint (include the full URL).
- Perform the action that triggers the bug (e.g., “Submit the form with the payload
<script>alert(1)</script> in the 'name' field"). - Describe the expected vs. actual result (e.g., "Expected: input is sanitized. Actual: alert executes on page load").
Do not assume the reviewer knows your local setup. If the bug only appears on a specific browser or OS, say so. If it requires a particular account type, mention that. The goal is to make the steps so clear that a different person can reproduce the issue without asking you for clarification.
Common Problems and How to Avoid Them
Several recurring issues turn potentially valid reports into rejected ones:
- Missing context: Reporting a vulnerability without the affected URL, parameter, or version. Always include the full URL and the relevant configuration.
- Overly broad claims: Saying "the whole site is vulnerable" without specifying which page or endpoint. Triage teams need a precise target.
- Unclear impact: A bug that has no security impact is often closed as informative. For example, a self-XSS that only affects the user themselves is rarely accepted.
- Using outdated payloads: Payloads that worked a year ago may be blocked now. Test your PoC against the current version before submitting.
- Ignoring the program's scope: Submitting a bug on a domain that is out of scope wastes everyone's time. Always read the program policy first.
Another frequent issue is submitting a report with a PoC that only works in the researcher's local environment (e.g., using a modified local DNS). The PoC must work on the program's own infrastructure.
Evidence Types Compared: Screenshots vs. Video vs. Raw Data
Different vulnerabilities call for different evidence formats. A screenshot is sufficient for a simple UI bug like a missing security header, but a complex logic flaw may need a screen recording to show the sequence of actions. Raw HTTP requests are the gold standard because they are machine-readable and can be replayed with tools like cURL or Burp Suite.
For example, an IDOR (Insecure Direct Object Reference) is best proven with two requests: one from a normal user accessing their own resource, and one from the same user accessing another user's resource by changing the ID. A screenshot of the second response showing the other user's data is clear, but including the full request/response pair makes it verifiable.
Screen recordings are useful for time-based or multi-step issues, but they are large and cannot be searched. Use them as a supplement, not a replacement for written steps.
Cost and Effort: What It Takes to Make a Report Actionable
Creating an actionable report takes time, but the effort pays off. A well-prepared report is more likely to be accepted and rewarded, and it reduces back-and-forth with triage. The cost is mostly in testing: you need to verify the bug on the current version, ensure it is not a false positive, and capture the evidence. This can take anywhere from 30 minutes for a simple reflected XSS to several hours for a complex business logic flaw.
Some programs offer a bonus for high-quality reports, but not all. The primary benefit is that your report is less likely to be closed as N/A (Not Applicable) or Informative, which means you save time and increase your chances of a bounty.
Safety and Ethical Considerations
When testing for bug bounties, always stay within the program's scope and rules. Do not use aggressive scanning tools that could disrupt the service. Avoid accessing or modifying data beyond what is necessary to prove the bug. If you accidentally access sensitive data, stop and report it immediately without downloading or storing it.
Never attempt to exploit a vulnerability to cause damage or to prove a point. The goal is to demonstrate the bug with minimal impact. For example, if you find an SQL injection, use a payload that returns a harmless value like 1=1 to prove the flaw, not one that dumps the entire database.
Frequently Asked Questions
What is the difference between a PoC and reproduction steps?
A Proof of Concept (PoC) is the actual demonstration of the vulnerability, such as a crafted URL or a script. Reproduction steps are the instructions that tell the reviewer how to trigger the PoC themselves. Both are needed: the PoC shows it works, and the steps allow the reviewer to confirm it independently.
Should I include a video in my bug report?
Videos are helpful for complex, multi-step vulnerabilities, but they are not always necessary. A clear set of written steps with screenshots and raw requests is often sufficient. If you include a video, keep it short and focused on the key actions and outcome.
How long should my report be?
There is no fixed length, but a good report is concise yet complete. Aim for a few paragraphs for the summary and impact, and a numbered list of reproduction steps. Avoid dumping huge log files or long transcripts; include only the essential parts.
What if I cannot reproduce the bug on the current version?
If you cannot reproduce it, do not submit the report. The vulnerability may have been fixed, or your initial test may have been flawed. Re-test on a clean environment and ensure you are using the correct payload and conditions.
Can I submit a report without a PoC?
In most programs, a report without a PoC is considered incomplete and will likely be closed as informative. The PoC is the core evidence that proves the vulnerability exists. If you cannot create a PoC, you probably do not have enough understanding of the bug to report it.
What should I do if my report is marked as N/A or Informative?
Read the triage team's comments carefully. They may have identified a misunderstanding or a missing piece of evidence. You can usually reply with clarifications or additional proof if you believe the issue is real. However, if the program states that the issue is out of scope or not a security vulnerability, accept the decision and move on.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.