report-writing

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:
       [email protected] (ID 123) successfully retrieved [email protected] (ID 456)
       orders, including their shipping address and payment method last 4 digits."

PERSISTENCE RULE

Every report-writing session must leave a complete finding folder on disk. Save the report draft, pre-submit checklist, references, downgrade counters, and final submission note under findings/<target-or-program>-<bug-class>/. Never rely on terminal or tmux scrollback for content the hunter needs later.

Minimum files:

findings/<target-or-program>-<bug-class>/
├── hackerone-report.md       # or bugcrowd-report.md / intigriti-report.md / immunefi-report.md
├── submission-notes.md       # final checklist, references, caveats, next action
└── evidence/                 # screenshots, curl output, response bodies when available

If tools/validate.py already wrote submission-notes.md, append/update it instead of creating a duplicate.

---

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