Writing Winning Reports

The difference between getting paid and getting ignored

What You'll Discover

Skills You'll Master

🔧 Report Template

Use this structure for every report. Each section has a purpose:

## Summary
[One sentence: What vulnerability, where, what's affected]
Purpose: Let triagers quickly understand the issue

## Vulnerability Type
[IDOR, XSS, SSRF, SQLi, etc.]
Purpose: Helps with categorization and assignment

## Steps to Reproduce
1. [Exact step - be specific]
2. [Exact step - include URLs, parameters]
3. [Exact step - what to click, what to observe]
Purpose: Someone unfamiliar with the app should reproduce in <5 min

## Impact
[What can an attacker do? What data is at risk? Who is affected?]
Purpose: Justifies severity rating and payout

## Proof of Concept
[Screenshots, HTTP requests/responses, video for complex bugs]
Purpose: Proves the vulnerability is real, not theoretical

## Suggested Fix (Optional)
[Brief recommendation, not code]
Purpose: Shows you understand the root cause

Key principle: Write as if the reader has never seen the application and has 5 minutes to validate your report.

Writing Effective Reports

Bad Report vs Good Report

The difference in quality directly affects whether you get paid:

"I found IDOR in your site. Plz fix."

## Summary
IDOR vulnerability in /api/invoices/{id} allows any
authenticated user to access other users' invoices
containing PII (names, addresses, purchase history).

## Vulnerability Type
IDOR (Insecure Direct Object Reference)

## Steps to Reproduce
1. Login as User A at https://<target>/login
   (I used test account: test-user-a@example.com)
2. Navigate to "My Invoices" in the dashboard
3. Open browser DevTools (F12) > Network tab
4. Click on any invoice to view it
5. Observe the request: GET /api/invoices/12345
6. Note User A's invoice ID (12345 in this example)
7. Modify the request to /api/invoices/12346
   (incrementing the ID by 1)
8. Observe: Invoice belonging to a DIFFERENT user is returned

## Impact
Any authenticated user can enumerate and access ALL invoices
in the system by iterating through IDs.

Each invoice exposes:
- Full legal name
- Home address
- Email address
- Complete purchase history
- Partial payment method (last 4 digits)

With approximately 50,000 users on the platform, this
represents significant PII exposure and GDPR compliance risk.

## Proof of Concept
[Screenshot: Two different users' invoices accessed from
single authenticated session]
[Burp request/response showing the API calls]

## Suggested Fix
Validate that the authenticated user owns the requested
invoice before returning data. The API should return 403
Forbidden for invoices belonging to other users.

Demonstrating Impact

Impact determines payout. Vague impact gets low severity; specific impact gets higher ratings:

# WEAK IMPACT (likely low payout)
"An attacker could read data."

# Why it's weak:
# - What data? User data, system logs, public info?
# - How much? One record, all records?
# - Who's affected? One user, all users?

# STRONG IMPACT (justifies higher severity)
"An attacker can access any user's:
 - Full legal name
 - Home address
 - Email address
 - Complete purchase history
 - Payment method details (last 4 digits of card)

 With approximately 50,000 users on the platform, this
 exposes significant PII and creates regulatory risk:
 - GDPR: Up to 4% of annual revenue in fines
 - CCPA: Up to $7,500 per intentional violation
 - PCI-DSS: Potential compliance violation

 Exploitation requires only authentication (any user
 can do this) and can be automated to dump all records
 in minutes."

# IMPACT QUANTIFICATION TECHNIQUES:
- Count affected users: "All 10,000 registered users"
- Estimate financial exposure: "Access to $X in transaction data"
- Identify compliance implications: GDPR, HIPAA, PCI-DSS
- Describe automation potential: "Can dump all records via script"
- Reference privilege escalation: "Could access admin panel"

Understanding CVSS Scoring

CVSS (Common Vulnerability Scoring System) is a standardized way to rate vulnerability severity on a 0-10 scale. Understanding CVSS helps you accurately rate vulnerabilities and justify your assessment.

Severity Levels and Examples

# CRITICAL (CVSS 9.0-10.0) - P1
Examples:
- Remote Code Execution (RCE)
- Authentication bypass to admin
- SQL injection with database access
- Account takeover affecting all users

Payout: Typically $1,000 - $50,000+

# HIGH (CVSS 7.0-8.9) - P2
Examples:
- IDOR exposing sensitive PII
- Stored XSS affecting many users
- SSRF with internal network access
- Privilege escalation

Payout: Typically $500 - $5,000

# MEDIUM (CVSS 4.0-6.9) - P3
Examples:
- Reflected XSS requiring user interaction
- CSRF on sensitive actions
- Limited information disclosure
- Open redirect (context-dependent)

Payout: Typically $100 - $1,000

# LOW (CVSS 0.1-3.9) - P4
Examples:
- Self-XSS (only affects yourself)
- Missing security headers (limited impact)
- Information disclosure without sensitive data
- Rate limiting issues with minimal impact

Payout: Typically $50 - $200

# INFORMATIONAL - P5
Examples:
- Best practice recommendations
- No demonstrated security impact
- Theoretical vulnerabilities

Payout: Usually none, or recognition only

CVSS Calculator Basics

Use the official CVSS calculator at https://www.first.org/cvss/calculator/3.1. Here's what the key metrics mean:

# ATTACK VECTOR (AV) - How can attacker reach the vulnerability?
Network (N):  Exploitable remotely over the internet
Adjacent (A): Requires same network segment (WiFi, LAN)
Local (L):    Requires local system access
Physical (P): Requires physical device access

# ATTACK COMPLEXITY (AC) - How hard is it to exploit?
Low (L):  No special conditions needed
High (H): Specific conditions or preparation required

# PRIVILEGES REQUIRED (PR) - What access level needed?
None (N):  Anyone can exploit (unauthenticated)
Low (L):   Requires normal user account
High (H):  Requires admin/privileged account

# USER INTERACTION (UI) - Does victim need to do something?
None (N):     Attacker can exploit directly
Required (R): Victim must click link, visit page, etc.

# IMPACT METRICS
Confidentiality (C): Can attacker read data? None/Low/High
Integrity (I):       Can attacker modify data? None/Low/High
Availability (A):    Can attacker disrupt service? None/Low/High

# EXAMPLE CVSS CALCULATIONS:
IDOR exposing all user data:
  AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 (Medium)

RCE via file upload:
  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Critical)

Reflected XSS:
  AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 (Medium)

Common Report Mistakes

Frequently Asked Questions

🎯 You Can Write Winning Reports!

Clear structure, specific reproduction steps, quantified impact, proper CVSS assessment - you now know how to write reports that get paid. Remember: the same vulnerability pays 10x more with a well-written report.

Ready to avoid duplicates and N/A closures