The exact structure, deadly mistakes, and pro tips that separate a $0 report from a $5,000 bounty

I’ve been on both sides.

I’ve written reports so bad that triagers couldn’t even understand what I found. I’ve also written reports so clean that they got triaged as Critical in under 3 hours with zero back-and-forth.

The difference wasn’t the vulnerability. It was the report.

You can find a real Critical vulnerability — RCE, SSRF, account takeover — and still get $0 if your report is unclear, incomplete, or unprofessional.

This article gives you the exact structure, the deadly mistakes to avoid, and the pro tips that will get your reports accepted faster and rewarded higher.

Why Your Report Matters More Than You Think

Triagers are humans. They review dozens of reports every single day.

A confusing report gets closed. A clear report gets paid.

Your report has one job: help the triager reproduce your finding in under 5 minutes. If they can’t do that, your report is dead — no matter how critical the bug is.

The Perfect Vulnerability Report Structure

Every good report has exactly 7 sections. Not more, not less.

1. Title (First Impression = Everything)

This is the most underrated part of any report. A bad title gets your report triaged slowly or dismissed immediately.

Bad Title Examples — Don’t Do This:

❌ XSS found
❌ SQL injection on website
❌ I found a bug in your system
❌ Security issue

Good Title Examples — Do This:

✅ Reflected XSS via `q` parameter on /search allows session 
   cookie theft from authenticated users
✅ SSRF via /api/fetch-url exposes AWS EC2 Instance Metadata 
   including IAM credentials
✅ IDOR in /api/v1/user/{id} allows any authenticated user to 
   read and modify other users' private data
✅ SQL Injection in /login `username` parameter - 
   Full database dump possible

Title Formula:

[Vulnerability Type] + [Where Found] + [What Impact]

2. Summary / Overview

2–4 lines maximum. Tell the triager:

• What is the vulnerability?
• Where exactly is it?
• What can an attacker do with it?

Example:

The /api/v1/fetch-url endpoint accepts a user-controlled URL parameter and makes a server-side HTTP request without any validation or allowlisting. An attacker can supply the AWS Instance Metadata URL (http://169.254.169.254/latest/meta-data/) to retrieve IAM credentials, potentially leading to full AWS account compromise.

Short. Clear. Impact stated upfront. Done.[docs.hackerone]​

3. 🌐 Vulnerability Details

Example:

Endpoint: https://target.com/api/v1/fetch-url
Parameter: url (POST body)
Method: POST
Type: Server-Side Request Forgery (SSRF)
Severity: Critical
CWE: CWE-918

4. Steps to Reproduce (Most Important Section)

This is where most reports fail.

Write numbered steps so clear that a junior intern could follow them and reproduce your bug in one attempt. Every step. No skipping.

Bad Example:

❌ Go to the website and test the URL parameter, 
   you will see SSRF.

Good Example:

   1. Log in to https://target.com with any valid account
   2. Navigate to Settings → Profile → Import Image from URL
   3. Intercept the request in Burp Suite
   4. Locate the POST request to /api/v1/fetch-url
   5. Modify the `url` parameter to:
      http://169.254.169.254/latest/meta-data/
   6. Forward the request
   7. Observe the server response contains:
      ami-id
      hostname
      iam/
      instance-id
   8. Send further request with url=
      http://169.254.169.254/latest/meta-data/iam/security-credentials/
   9. Observe IAM role name returned in response
   10. Send final request to retrieve temporary AWS credentials

Golden Rule: If you have to say “you’ll see the bug” — you haven’t written enough steps.

5. Proof of Concept (PoC)

Your PoC is your evidence. Without it, your report is just a claim.[intigriti]​

Always include:

• ✅ Screenshots — Every step, every response, every sensitive data exposed
• ✅ Burp Suite request/response — Raw HTTP request showing the payload and response
• ✅ Video recording — For complex bugs or chained attacks
• ✅ curl command — So the triager can reproduce instantly:

curl -X POST https://target.com/api/v1/fetch-url \
  -H "Cookie: session=YOUR_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

Pro Tip: Use Burp’s “Copy as curl command” feature — right click on any request → Copy as curl. Paste it directly into your report. Triagers love this.

6. Impact (Where Bounty Amount Is Decided)

Most beginners write this badly. They say:

❌ "This is dangerous and could harm users."
❌ "Attacker can steal data."
❌ "Critical vulnerability, please fix."

This is useless. Be specific and realistic — don’t over-exaggerate, don’t downplay.

Good Impact Example:

✅ An unauthenticated attacker can exploit this SSRF vulnerability to:
1. Retrieve temporary AWS IAM credentials from the EC2 metadata service
2. Use those credentials to access S3 buckets containing user PII data
3. Read RDS database snapshots
4. Potentially pivot to full AWS account takeover depending on IAM role permissions
This vulnerability affects ALL users of the platform as their 
personal data stored in S3 is at risk. The CVSS Base Score is 
9.8 (Critical) due to network-accessible attack vector, no 
authentication required, and high impact on confidentiality, 
integrity, and availability.

Format your impact as:

• What can the attacker do? (Step by step)
• Who is affected? (All users / admins only / specific roles)
• What data is at risk? (PII / credentials / financial data)
• What is the worst-case scenario?

7. Remediation / Fix Recommendation

Always include a fix. This shows professionalism and saves the developer time.​

Example for SSRF:

Recommended Fixes:
1. Implement a strict allowlist for outbound HTTP requests
   — Only allow requests to pre-approved domains
2. Block requests to private IP ranges:
   — 169.254.0.0/16 (AWS metadata)
   — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (internal networks)
3. Enable IMDSv2 (token-based) on all EC2 instances to 
   prevent unauthenticated metadata access
4. Validate and sanitize all URL input parameters server-side

10 Deadly Mistakes That Get Reports Rejected

These are the most common reasons why valid bugs get rejected or get $0:

1. Out of Scope Submission
You didn’t read the program scope. Target wasn’t in scope. Instant rejection. Always read the scope before hacking — every single time.

2. Duplicate
Someone else already found and reported it. Not your fault — but check if a public disclosure exists before submitting.

3. No Real Impact
“Self-XSS” where the attacker needs physical access to victim’s browser — this is N/A. “Missing security headers” without real exploitability — this is Informational. Every report needs demonstrable real-world impact.

4. No Proof of Concept
A report with no screenshots, no request/response, no curl command — gets closed immediately.

5. Non-Reproducible Steps
Triager cannot reproduce it. Either your steps are incomplete or environment-specific. Always test your own reproduction steps before submitting.

6. Vague Title
“SQL Injection found” tells the triager nothing. They’ll deprioritize it instantly.

7. Overestimated Severity
Calling a low-impact CSRF “Critical” destroys your credibility with triagers. Be honest. Overestimating severity is one of the fastest ways to get flagged as a low-quality researcher.

8. Submitting Theoretical Bugs
“This parameter could be vulnerable to XSS if someone adds <script> here" — this is not a real finding. Always confirm and demonstrate the exploit before submitting.

9. Poor English / Unreadable Format
Triagers skip reports that require too much effort to understand. Use markdown properly — headers, code blocks, numbered lists.

10. Multiple Bugs in One Report
One report = One vulnerability. If you found XSS on 3 subdomains, submit once and mention all 3 — don’t submit 3 separate reports.

Pro Tips That Separate Good Hunters From Great Ones

These are the habits that elite bug hunters have but rarely talk about:

💡 Tip 1 — Draft First, Submit Second
Write the report in Notion or Obsidian. Sleep on it. Read it again the next morning. If something is confusing, fix it before submitting.

💡 Tip 2 — Use the “Intern Test”
Ask yourself: “If a junior intern with no context read this report, could they reproduce the bug?” If no — keep writing.

💡 Tip 3 — Separate PoC Accounts
Always create a separate test account for demonstrating impact. Never use your own personal data in PoC screenshots.

💡 Tip 4 — Show the Attack Chain
A single XSS might be Medium. But XSS + CSRF + session theft chained together becomes High or Critical. Show the full chain if it exists.

💡 Tip 5 — Respond Quickly to Triagers
When a triager asks for more info, respond within 24 hours. Slow responses lead to closed reports. Treat it like a professional conversation.

💡 Tip 6 — Keep a Personal Report Template
Once you have a format that works, save it as a template. Never start from scratch again.

Your Ready-to-Use Report Template

Copy this for every submission:

## Summary
[2-3 lines: What is the bug, where, what impact]
## Vulnerability Details
- **URL:** 
- **Parameter:** 
- **HTTP Method:** 
- **Type:** 
- **Severity:** 
- **CWE:**
## Steps to Reproduce
1. 
2. 
3. 
4. 
5. 
## Proof of Concept
[Screenshots / Burp Request / curl command]
## Impact
An attacker can:
1. 
2. 
3. 
Affected users:
Worst case scenario:
CVSS Score: 
## Remediation
1. 
2. 
3. 

Run through this before every submission:

• Is this target in scope?
• Is this vulnerability in the qualifying list?
• Is my title descriptive (Type + Location + Impact)?
• Are my reproduction steps numbered and complete?
• Did I include screenshots for every step?
• Did I include a curl command or raw Burp request?
• Is the impact clearly explained? (Not theoretical — demonstrated)
• Did I suggest a remediation?
• Is this possibly a duplicate of my own previous report?
• Is this one vulnerability only in this report?

All 10 checked? Submit. 🚀

Final Thought

Finding a bug is 50% of bug bounty. Writing the report is the other 50%.

I’ve seen Critical vulnerabilities get closed as “Not Applicable” because the hunter couldn’t explain the impact. I’ve also seen Medium vulnerabilities get triaged in 2 hours and paid immediately because the report was clean, detailed, and professional.

Your report is your product. Polish it.

I’m @HackerMD — cybersecurity researcher and bug bounty hunter from India. Follow for real writeups, automation scripts, and practical security guides.

#BugBounty #Cybersecurity #Ethical Hacking #Infosec #PenetrationTesting