Englishবাংলা
SubscribeWrite
Latest
Binary search: patterns, templates and common pitfallsDocker's $250 Cloud Sandboxes credit: what it covers and what it does notTwo pointers and sliding window: patterns with examplesArrays and hash maps: the interview patterns you must knowBig-O notation explained: time and space complexity for interviewsSoftware testing basics: the test pyramid and what to testClean code and code review habits that make you a better developerREST API design best practices: URLs, status codes and errors

How to write a bug bounty report that gets triaged fast

Two researchers can find the same bug and get different outcomes because of the report. Use this template to be clear, fast to verify and professional.

••2 min read
A structured report document with sections

Triage analysts read many reports every day. A report that is easy to understand and reproduce gets accepted faster and is more likely to be rated correctly.

The template

1. Title. Specific and short. Say what and where.

  • Weak: "XSS found"
  • Good: "Stored XSS in the comment field on /blog/{id} allows script execution for other users"

2. Summary. Two or three sentences: what the bug is, where it is, and what it lets an attacker do.

3. Affected asset and scope. The exact URL, endpoint or app, plus confirmation that it is in scope. Include the environment and version if relevant.

4. Steps to reproduce. Numbered, exact and complete, from a fresh state:

  1. Create two test accounts, A and B.
  2. Log in as A and open /invoices/1001.
  3. Replace the ID with 1002 (an invoice owned by B).
  4. Observe B's invoice returned with status 200.

Include the exact requests (a copy of the HTTP request and response), parameters and any required headers. Someone who has never seen the bug should reproduce it in minutes.

5. Proof of concept. Screenshots, a short video, or logs. Use harmless proof only (for example, showing your own second test account's data, not real users' data).

6. Impact. Explain what could realistically happen to users or the business: data exposure, account takeover, financial loss. Be factual, and do not exaggerate. State what you did not do (you did not access real user data).

7. Severity suggestion. Offer a rating with a short reason, ideally using the program's scale or CVSS. Triage may adjust it.

8. Suggested fix. One or two lines, such as "check that the invoice belongs to the current user on the server". It helps the engineers and shows understanding.

9. Extra context. Related endpoints with the same flaw, browser or tool versions, and your testing times, in case logs are checked.

Common mistakes that get reports closed

  • Missing impact: "I can change this header" without showing why it matters.
  • Scanner output pasted as a report without verification.
  • Theoretical issues with no working proof.
  • Out of scope or excluded findings (read the exclusions list).
  • Vague steps such as "go to the page and inject payload".
  • Overstated severity, which costs you trust.
  • Several unrelated bugs in one report. Submit them separately.
  • Public disclosure before permission.
  • Rude or pressuring tone in comments.

During and after triage

  • Answer questions quickly and politely.
  • If asked for more proof, give it safely.
  • If it is closed as informative or not applicable, read the reason, learn from it, and move on. Disagree respectfully with new evidence, not repeated demands.
  • Retest the fix if asked.

A short checklist before you press submit

  • Can a stranger reproduce it from my steps alone?
  • Did I show real, realistic impact?
  • Did I stay in scope and avoid touching real users' data?
  • Is the title specific?

Takeaway: a good report is specific, reproducible, honest about impact and polite. Use the template every time.

Bug Bounty series, Part 1 (getting started): 3 of 4. Previous: Bug bounty platforms: how to choose where to start.

Keep reading