📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
$
Here is the thing about bug bounty that nobody explains clearly enough: finding the vulnerability is only half the job. The other half is how to report bug bounty vulnerability i.e. writing a report that convinces a triage engineer — who may review hundreds of reports per week — that your finding is real, reproducible, impactful, and worth paying for. Technically valid findings get marked N/A every day because the report was unclear, the impact was understated, the reproduction steps were incomplete, or the severity was misjudged. The vulnerability was real. The report failed.
This guide gives you the exact report template, the impact statement formula, the severity framework, real paid report examples, and the nine most common reasons valid findings earn nothing. If you have already found something and you are wondering how to write it up — this is the article you need before you submit.
💡
This article is for people who have already identified a potential vulnerability. If you are still building the skills to find vulnerabilities, start with the Bug Bounty Beginners Guide and the 60-Day Bug Bounty Course first.
📋 Contents
Before You Write — Confirm the Finding
The Complete Report Template
The Title Formula
Writing the Impact Statement
Severity Rating Framework
Proof-of-Concept Requirements
3 Real Report Examples (Paid)
9 Reasons Reports Get N/A
Before You Write — Confirm the Finding First
Every report begins before you open the submission form. If you skip these steps, you risk submitting a duplicate, an out-of-scope finding, or one you cannot reproduce — all of which waste triage time and damage your platform reputation.
1
Reproduce it with two test accounts
Every IDOR, access control bypass, or authentication flaw must be demonstrated cross-account — Account A accessing Account B’s data. If you only have one account, create a second before reproducing.
2
Verify the endpoint is in scope
Check the programme’s scope document. Is the exact subdomain or API endpoint explicitly in scope? “*.company.com” may or may not include admin.company.com — read the exclusions carefully. When in doubt, ask in a support ticket before testing.
3
Check for duplicates
Search the programme’s disclosed report timeline for the same vulnerability type on the same endpoint. A duplicate earns nothing and counts negatively on some platforms. If you find a similar report, check if it was fully remediated or if your finding is a bypass of the original fix.
4
Screenshot every step now
Before writing a word, capture every reproduction step with screenshots. Show the normal behaviour, the modified request (with the changed parameter highlighted), and the vulnerable response (with the exposed data highlighted). Annotate with red arrows or boxes.
The Complete Report Template — Every Section Explained
securityelites.com
SecurityElites — New Report Submission — The Winning Structure
① TITLE — [VULN TYPE] in [COMPONENT] allows [SPECIFIC IMPACT]
IDOR in /api/v2/documents/{id} endpoint allows any authenticated user to download private documents belonging to other users
② VULNERABILITY DESCRIPTION — What it is, where, why
The document download endpoint /api/v2/documents/{id} accepts an integer document ID in the URL path. This ID is not validated against the authenticated session’s user ID — any authenticated user can substitute any integer and receive the file regardless of ownership. The application relies on the client to supply the correct document ID, with no server-side ownership verification.
③ STEPS TO REPRODUCE — Numbered, exact, from scratch
- Register two test accounts: attacker@test.com (Account A) and victim@test.com (Account B)
- Log in as Account B → upload a private document → note the document ID in the URL: /documents/18443
- Log out of Account B → log in as Account A
- In Burp Suite Repeater, send: GET /api/v2/documents/18443 with Account A’s session cookie
- Observe: Account B’s private document is returned in the response body — full content, no authorisation error
④ IMPACT — Who, what data, how many users, real-world harm
Any authenticated user can enumerate all document IDs by iterating integers and download any document on the platform — including contracts, invoices, medical records, legal documents, and any other sensitive content uploaded by any user. With [X] million registered users and [Y] documents in the system, a single authenticated attacker can exfiltrate the complete document corpus. This constitutes a full platform-wide data breach exploitable by any account holder.
⑤ PROOF OF CONCEPT
Screenshots attached: (1) Account B uploading document — ID 18443 visible in URL. (2) Burp Repeater — GET /api/v2/documents/18443 with Account A session cookie. (3) Response — document content returned, HTTP 200, no authorisation error. (4) Side-by-side: Account B’s document matched to Account A’s response.
Severity Self-Assessment
HIGH — Mass data exposure, all users affected
Complete Bug Bounty Report Template — Five sections: Title (formula), Description (technical), Steps to Reproduce (numbered, exact), Impact (specific), Proof-of-Concept (screenshots). Every section is mandatory. Reports missing any one section are frequently triaged as informative or N/A regardless of finding validity.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)