iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An actionable bug bounty report lets a reviewer start from a clean state, follow your exact steps, observe the same security failure, and understand the real-world consequence without guessing. It names the in-scope target, states prerequisites, provides an ordered reproduction path, includes proportionate proof, and ties the demonstrated behavior to a realistic impact. A vulnerability label alone is not enough.
What “actionable” means to a triage team
Actionability is the combination of verifiability and decision-ready context. The reviewer should be able to answer five questions from the report itself:
- Where does the issue occur, and is that asset in scope?
- What account, role, configuration, or victim interaction is required?
- Which exact actions, requests, parameters, or inputs trigger the behavior?
- What should the system do, and what does it actually do?
- What capability or harm does the demonstrated behavior create?
HackerOne’s Code of Conduct summarizes the standard this way: “Reports must be accurate, reproducible, and demonstrate real-world impact.” Its Help Center defines a quality report as one that provides “clear, detailed, and actionable information about a vulnerability.” Bugcrowd’s researcher guidance similarly says a report should explain where the bug was found, who it affects, how to reproduce it, which parameters it affects, and provide proof-of-concept supporting information.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesThese are platform standards, not a guarantee that every program uses the same form, severity rubric, or triage outcome. A complete report can still be closed as duplicate, out of scope, not applicable, or insufficient impact; your job is to make the technical finding easy to verify and assess.
#1 Best Overall
Start with a precise title and target
The title is a triage shortcut. It should identify the vulnerability class, affected feature or location, and meaningful demonstrated consequence in plain language. Avoid titles such as “XSS found” or “security issue on the site.” They force the reviewer to open the report before learning what is affected.
A useful pattern is:
[Vulnerability] in [feature or endpoint] allows [demonstrated impact]For example, “Horizontal authorization bypass in invoice download endpoint exposes another user’s invoice” tells the reviewer more than “IDOR.” Do not claim account takeover, arbitrary code execution, or broad data exposure unless your proof of concept actually demonstrates that result.
Identify the in-scope asset
State the program asset exactly as it appears in the scope list, then give the URL, application area, endpoint, parameter, or API route where the behavior occurs. Include the HTTP method, host, path, and relevant parameter names when they matter. If the same defect appears on several routes, list each affected route and explain whether the behavior is identical or merely related.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Separate location from impact
The target tells the team where to look. The impact tells them why the issue matters. Keep both in the title when possible, but provide the full technical detail in the body rather than packing every implementation fact into one sentence.
Use a report structure that mirrors the reviewer’s decisions
A consistent structure prevents missing context. The following sections cover the information most programs request, although field names differ.
- Title: vulnerability, affected feature or target, and demonstrated impact.
- Target and location: exact in-scope asset, URL, endpoint, parameter, or application area.
- Summary: one or two sentences describing the defect and security consequence.
- Preconditions: required role, account state, configuration, victim interaction, or timing dependency.
- Steps to reproduce: numbered actions in the order a reviewer should perform them.
- Expected versus actual behavior: the secure result compared with the observed result.
- Evidence or proof of concept: the smallest useful request, response, script, screenshot, or recording.
- Impact: attacker capability, affected parties or data, reach, and realistic consequence.
- Severity: the program’s requested rating or CVSS information, supported by demonstrated facts.
- Remediation direction (optional): a concise, technically sound suggestion when you can provide one.
Bugcrowd’s researcher form groups its content as overview, walkthrough or proof of concept, vulnerability evidence, and demonstrated impact. HackerOne forms may add custom fields or require severity selection. Treat the platform’s live form and the individual program policy as authoritative when they differ from this general structure.
Write reproduction steps a stranger can execute
Reproduction steps should begin at a defined state and end at an observable security failure. Number every action; do not hide setup in prose or assume the reviewer knows which account, browser state, or request you used.
1. State prerequisites before the first action
List only what is necessary, but list it explicitly:
- Account roles, such as ordinary user, administrator, or two separate users.
- Whether the account must own a resource, have a subscription, or complete a workflow first.
- Required configuration, feature flag, API key, device, browser state, or authentication method.
- Whether a second user must exist and what that user owns.
- Any timing window, race condition, or victim interaction.
Use neutral labels such as attacker@example.test and victim@example.test in examples, and explain which account performs each step.
2. Identify the starting state
Tell the reviewer where to begin: logged out, newly registered, on a specific dashboard, with a draft object created, or with a captured request ready to resend. If a clean account is required, say so. If the issue depends on an existing object, give the object type and the permission relationship rather than exposing real customer data.
3. Give one action per numbered step
Each step should contain the action and the concrete value used. Include a URL, HTTP method, parameter, header, body, or UI label when relevant. A reviewer should not have to infer whether a value is URL-encoded, case-sensitive, sequential, signed, or copied from a previous response.
4. Show the transition that matters
Explain what changes after each important action: a session cookie is issued, an object identifier is returned, a role changes, or a request is accepted. For multi-request exploits, label requests in order and identify which value is carried forward.
5. End with an observable result
State exactly what the reviewer should see or receive: another user’s invoice contents, an unauthorized status change, a server-side request, a reflected script execution, or a response containing a secret. Include a distinctive response field, status code, or UI message when it helps confirm success.
6. State expected and actual behavior
Expected behavior is the secure outcome, such as a 403 Forbidden response, an object-ownership check, or rejection of an untrusted redirect. Actual behavior is what your test produced. This comparison distinguishes a security defect from an unusual but permitted feature.
Example of a complete reproduction block
The following format is intentionally generic; replace every value with facts from your finding.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePrerequisites
- User A has a standard account and owns invoice 1001.
- User B has a standard account and owns invoice 2002.
- User A is authenticated in one browser session.
Steps
1. As User A, open the invoice download request for invoice 1001.
2. Capture GET /api/invoices/1001/download.
3. Replace the path identifier 1001 with 2002 and resend the request using User A’s session.
4. Observe the response body and status code.
Expected
The server verifies ownership and returns 403 Forbidden (or an equivalent denial).
Actual
The server returns 200 OK and the PDF for User B’s invoice.This example identifies the roles, object relationship, route, changed value, expected authorization decision, and observable result. It does not claim that every invoice endpoint behaves this way; your report must document the route and response you actually tested.
Choose evidence that proves the claim with minimal noise
Evidence is useful when it lets the reviewer confirm the relevant behavior quickly. It is not a substitute for written steps. Select the format that best demonstrates the particular finding and that the program permits you to submit.
| Evidence type | Best use | Strength | Risk or limitation |
|---|---|---|---|
| Written steps | Every finding, especially UI and workflow issues | Searchable, reproducible, and easy to audit | Fails if prerequisites or exact inputs are omitted |
| Request/response excerpt | API, authorization, injection, and protocol findings | Shows the precise input and server result | Must redact tokens, cookies, personal data, and unrelated fields |
| Script or code snippet | Repeatable sequences, parsing, or multi-step automation | Can reduce manual ambiguity | Needs setup instructions and must stay within authorized scope |
| Screenshot | Visible UI state, error, or exposed data type | Quickly confirms what a user can see | Usually cannot establish a complete exploit path alone |
| Screen recording | Timing, multi-step UI flows, or interaction-dependent behavior | Shows sequence and visual context | Harder to search; video alone is insufficient under HackerOne’s published conduct guidance |
Attach the smallest artifact that proves the point. A short request and response may be stronger than a long capture of unrelated traffic. A recording can supplement numbered steps when a race, timing issue, or complex interface is difficult to describe, but retain the written procedure even when an attachment is present.
Redact before uploading
- Remove passwords, session cookies, API keys, authorization headers, reset links, and private signing material.
- Replace third-party names, email addresses, identifiers, and documents with synthetic values when they are not necessary to prove the issue.
- Crop screenshots and recordings to the relevant application area.
- Check archives and source files for hidden metadata or copied secrets.
- Explain any redaction that could otherwise make the reproduction appear incomplete.
Never collect more data than needed to demonstrate the issue. If your proof exposes real personal information, stop, preserve only the minimum necessary evidence, and follow the program’s reporting instructions.
Recommended Free Tools
Explain impact as an attacker capability
Impact is more than a severity label. Describe what an attacker can do, what access they need, whose data or functionality is affected, and how far the demonstrated path reaches.
Describe the required attacker position
State whether exploitation requires no account, a normal account, a privileged role, a compromised user, physical access, or cooperation from another person. Mention whether the attacker must know an identifier, defeat a control, win a race, or persuade a victim to click.
Describe the demonstrated capability
Use concrete verbs: read, modify, delete, impersonate, execute, redirect, upload, or trigger. Identify the object or operation and its boundary. “Can read another user’s invoice through this endpoint” is stronger and more accurate than “full database compromise.”
Describe affected parties and reach
Explain whether the result affects one object, one account, a tenant, or potentially many users. If you tested only your own accounts, say that and distinguish the tested result from a broader possibility. Do not infer organization-wide exposure from a single successful record unless the evidence supports that scope.
Account for mitigations and context
Note controls that reduce or change the risk: rate limits, required interaction, short-lived tokens, logging, content-security policy, approval workflows, or a permission that limits the affected population. A mitigation does not automatically eliminate the vulnerability, but omitting it can make your severity assessment inaccurate.
Set severity from facts, not labels
Use the program’s requested rubric and, when required, provide CVSS information. HackerOne’s submission guidance references a CVSS calculator, while individual programs may use custom fields or different definitions. Beginning September 21, 2026, HackerOne says severity selection is required for Bug Bounty, Vulnerability Disclosure, and Challenge programs that require severity, unless a program opts out; check the live submission form because settings vary.
Support the rating with the prerequisites, attack complexity, privileges, user interaction, affected confidentiality, integrity, and availability, as applicable. If the evidence proves unauthorized reading of one object, do not rate it as unrestricted account takeover. If the program’s baseline classification differs from your assessment, explain the demonstrated facts and let the team apply its policy. Bugcrowd notes that its Vulnerability Rating Taxonomy is a baseline and that the final rating can change when impact is considered.
Stay inside scope, privacy, and disclosure rules
Read the program brief before testing. Scope controls assets, methods, accounts, automation, and acceptable proof. Stop when the next action would exceed the authorization you were given. Hazardous testing, service disruption, bulk data access, social engineering, physical intrusion, or attacks on third parties may be prohibited unless explicitly authorized.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not include third-party personal information in a report when synthetic or redacted evidence can prove the issue. If sensitive data appears unexpectedly, avoid further access and report the minimum necessary details through the approved channel.
Disclosure is not uniform. HackerOne’s guidance ties publication to the program’s disclosure settings and policy. Bugcrowd warns that private-program vulnerability information must remain confidential unless the program allows disclosure. Do not promise a universal disclosure deadline, publication right, or bounty. Some teams offer rewards, but not all; the security team determines eligibility and amount.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common reasons a report is marked not reproducible
Missing account or role context
A reviewer uses an ordinary account when your exploit required an administrator, a newly created user, or two separate accounts. Put the role and account relationship in prerequisites and label each step by actor.
Stale or one-time values
Identifiers, links, nonces, and tokens may expire or be tied to a session. Explain how to generate a fresh value and which response field supplies it. Do not paste a live secret that could expose an account.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Unclear request details
“Change the ID and resend” is incomplete if the method, path, encoding, body, or header matters. Include a sanitized request excerpt and identify exactly what changed.
Best Value
Timing or configuration omitted
Race conditions, cache state, feature flags, regional settings, and browser behavior can determine the result. Record the order, interval, concurrency, configuration, and environment that are necessary, then state which dependencies are essential.
Evidence shows an error, not impact
A stack trace, reflected string, or unusual status code is not automatically a security consequence. Show the unauthorized action, data access, privilege change, or other capability that follows, and explain what a user or attacker can actually achieve.
Video submitted without a written path
A reviewer should not have to scrub through a recording to discover setup or inputs. Keep numbered steps and a concise impact statement in the report; use video only as supporting evidence.
Free tools Windows power users keep installed
One-click scans. No signup required.
Pre-submission quality check
- The title names the vulnerability, target feature, and demonstrated consequence.
- The asset, URL, endpoint, method, and parameter are in scope and clearly identified.
- Prerequisites include every required role, account, configuration, and timing dependency.
- Steps are numbered, ordered, and executable from a defined starting state.
- Inputs, requests, and expected-versus-actual behavior are concrete.
- Evidence proves the result, is proportionate, and contains no unnecessary secrets or personal data.
- Impact states attacker access, affected capability or data, reach, and relevant mitigations.
- Severity follows the program’s current rubric and is supported by the proof of concept.
- Any remediation suggestion is optional, concise, and technically sound.
- Scope, testing, confidentiality, and disclosure rules have been checked immediately before submission.
A reusable report template
Title:
[ vulnerability ] in [ feature/target ] allows [ demonstrated impact ]
Target and location:
- In-scope asset:
- URL/endpoint and method:
- Parameter or application area:
Summary:
[One or two sentences describing the defect and consequence.]
Prerequisites:
- Account role(s):
- Required objects or configuration:
- Victim interaction, timing, or other dependency:
Steps to reproduce:
1. [Actor] [action, URL, input, or request].
2. [Actor] [next action and exact value].
3. [Observable transition].
4. [Final action].
Expected behavior:
[Secure result.]
Actual behavior:
[Observed result, including relevant status, field, or UI output.]
Proof of concept/evidence:
[Sanitized request-response, script, screenshot, or recording description.]
Impact:
[Required attacker access, capability gained, affected parties/data, reach, and mitigations.]
Severity:
[Program field or CVSS details, with factual justification.]
Optional remediation direction:
[Short suggestion, only if reliable.]Before submitting, run the procedure from a clean session or test account if the program permits it. Confirm that every attachment matches the written steps and that your claims stop at what the proof demonstrates.
Frequently Asked Questions
Is a screen recording enough to make a bug bounty report actionable?
No. Use the recording as supplementary evidence and include complete written prerequisites, numbered steps, expected-versus-actual behavior, and impact. HackerOne’s conduct guidance warns that reports based solely on a video attachment may be closed as Not Applicable.
Should I include a CVSS score in every report?
Only when the program requests it or provides a severity field. Follow the live form and program policy; where a score is requested, justify it from the demonstrated attack prerequisites and impact rather than from the vulnerability name alone.
What should I do if my proof of concept reveals real personal data?
Stop accessing additional records, retain only the minimum evidence needed, redact the data, and follow the program’s approved reporting channel. Do not include third-party PII when synthetic values can demonstrate the issue.
Can I publish a report after submitting it?
Not automatically. Disclosure depends on the program’s policy and settings. Keep private-program information confidential unless the program explicitly permits disclosure, and do not assume a universal publication period or bounty.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
