Writing reports triagers love

Triage teams read a lot of reports. The ones that get validated quickly share the same qualities: they are clear about impact, easy to reproduce and backed by evidence. None of that requires more words — usually it requires fewer.

Lead with impact

Your title and first sentence should say what an attacker can do, to whom, and under what conditions. "Any logged-in user can read other customers' invoices by changing the invoice ID" is far stronger than "IDOR on /api/invoices". The triager should understand the severity before they scroll.

Give minimal, numbered steps

Write reproduction steps someone else can follow exactly, starting from a clean state. Include the accounts or roles involved, the exact requests, and the parameter you changed. Remove anything that is not needed to reproduce the issue. If a step depends on timing or a specific setting, say so.

Attach proof, not noise

Include the raw request and response, a screenshot of the result, or a short video for complex flows. Redact real customer data you encountered and stop as soon as you have proven the issue — accessing more data than needed weakens your report and can breach the program's rules.

Stay in scope

Read the program policy before testing, and again before submitting. Out-of-scope assets and excluded vulnerability types are the most common reasons reports are closed without reward. If you are unsure whether something counts, ask the program through the platform before you dig deeper.

Respond quickly

Triagers sometimes need a detail clarified. A fast, precise reply keeps your report moving and builds the reputation that earns invitations to private programs.