Bug-bounty report & severity

When it governs

After you've reproduced a finding and confirmed it's in scope. A great report gets triaged fast and paid fairly; a sloppy one gets closed as informational regardless of the bug.

Structure (what triagers want)

1. Title — [Vuln class] on <asset> allows <impact> (specific, no hype).
2. Summary — 2–3 sentences: what, where, why it matters.
3. Severity — CVSS 3.1 vector + score, reconciled with the program's VRT/policy. Justify the Impact metrics from demonstrated impact, not theoretical maximum.
4. Steps to reproduce — numbered, copy-pasteable, from a clean session. Include exact requests (method, URL, headers, body) and account roles used.
5. Proof — minimal PoC that proves impact (a screenshot with the URL bar, a request/response pair, a short video). document.domain for XSS; sts get-caller-identity for cloud, etc.
6. Impact — the realistic business consequence, tied to what you proved.
7. Remediation — the correct fix (allowlist, output encoding, object-level authz…).