REPORT WRITING

Impact-first. Human tone. No theoretical language. Triagers are people.

---

THE MOST IMPORTANT RULE

Never use "could potentially" or "could be used to" or "may allow". Either it does the thing or it doesn't. If you haven't proved it, don't claim it.

BAD:  "This vulnerability could potentially allow an attacker to access user data."
GOOD: "An attacker can access any user's order history by changing the user_id
       parameter to the target user's ID. I confirmed this using two test accounts:
       attacker@test.com (ID 123) successfully retrieved victim@test.com (ID 456)
       orders, including their shipping address and payment method last 4 digits."

---

TITLE FORMULA

[Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope]

Good titles (specific, impact-first):

IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data
Missing auth on POST /api/admin/users allows unauthenticated attacker to create admin accounts
Stored XSS in profile bio field executes in admin panel, allows privilege escalation
SSRF via image import URL parameter reaches AWS EC2 metadata service
Race condition in coupon redemption allows same code to be used unlimited times

Bad titles (vague, useless to triager):

IDOR vulnerability found
Broken access control
XSS in user input
Security issue in API
Unauthorized access to user data

---

HACKERONE REPORT TEMPLATE

## Summary

[One paragraph: what the bug is, where it is, what an attacker can do. Be specific.
Include: endpoint, method, parameter, data exposed, required access level.]