Report like a professional
Severity, evidence, reproduction: the three parts every finding needs.
A finding has three load-bearing parts, and a report missing any one of them gets ignored no matter how severe it sounds. This is the same shape BugHunt submissions, Rampart findings, and Bolt investigations all consume — learn it once, use it everywhere.
1. Severity: how bad if true
Severity judges impact times exploitability, not cleverness. A reflected XSS on an admin panel that fires on login is high; the same XSS on a static page nobody visits is low. Ask: who is affected, what do they lose, and what must the attacker already have? Then pick the tier whose definition fits — never the tier that feels rewarding.
Common inflation traps: calling missing headers a vulnerability (it is a note), rating by exploit sophistication instead of victim impact, and forgetting preconditions (admin-only + ten steps is not critical). Reviewers downgrade fast and remember who inflates.
2. Evidence: show, don't paraphrase
Paste the tool output, the response headers, the log line — the artifact itself, trimmed to the relevant lines. Paraphrase loses the detail that lets a stranger verify; screenshots help but never substitute for copy-pasteable text. Redact secrets and other customers' data before you paste, and say what you redacted.
Separate evidence from inference with labels. Observed: GET /admin returned 200 with the user list. Then Inference: any unauthenticated visitor can enumerate accounts. The seam between the two is exactly where reviewers check your work.
3. Reproduction: exact steps
Numbered steps a stranger can follow with no questions: starting state, each request or action verbatim, expected vs actual result at each step. Include tool versions where they matter (curl 8.x, the exact payload string). End with the fix suggestion — the parameterized query, the missing check, the header to add — because findings with fixes get prioritized and findings without get deferred.
Template for every finding:
Title: Unauthenticated admin panel exposes user list
Severity: High — full PII disclosure, no credentials needed
Evidence: GET /admin → 200, 14 user rows incl. emails (see below)
Steps: 1. Fresh browser, no cookies. 2. GET https://shop.test/admin
3. Observe 200 + user table (expected: 302 to /login)
Fix: Require the admin session middleware on /admin*;
add a regression test for unauthenticated GET.
Key takeaways
- Severity = impact × exploitability, judged by definitions, not feelings.
- Evidence is pasted artifacts; inference is labeled as yours.
- Reproduction steps must work for a stranger — claim, evidence, steps, fix.
That was the whole lesson.
A free account adds the interactive part: the marking quiz, the lab if this lesson carries one, live progress, the timed exam, and a certificate employers can verify.

