Writing findings

The finding is the only deliverable that matters

Everything earlier in this unit — authorization, the toolkit, the methodology — exists to produce one artifact: a finding the customer can fix. A penetration test isn’t graded on how many bugs you found; it’s graded on how many got closed, and a bug only closes when an engineer who wasn’t on the engagement can reproduce it, understand why it matters, and apply a fix. That shifts the whole frame: your audience is not another hacker who’ll be impressed by the exploit, it’s a busy backend engineer with forty other tickets who will deprioritize anything they can’t immediately act on. A finding written for the wrong audience is a finding that stays open — which, for the business, is identical to a vulnerability you never found.

So a finding is a unit of work, not a brag. The senior discipline is to write every finding so that a stranger can pick it up cold and drive it to closure without asking you a single question.

The four parts every finding needs

A finding that closes carries four things, and dropping any one of them is the difference between the two reports in the Hook.

Reproduction is the part juniors skip and seniors lead with, because it’s the part that converts a claim into a fact. The engineer should be able to follow your steps and watch the bug happen on their own machine: the exact endpoint, the two test accounts and which is which, any preconditions (logged in as a low-privilege user, a specific record id), the precise request you sent, and — critically — the expected vs actual result so the violation is unambiguous. “Account B requested account A’s invoice and received it (expected: 403)” leaves nothing to interpret. Without this, the first thing the customer does is fail to reproduce, and a finding nobody can reproduce gets closed as won’t-fix no matter how real it is.

Impact answers so what. Severity is a number; impact is the sentence that earns the number. The trap is writing the generic impact (“IDOR can lead to unauthorized data access”) instead of the concrete one for this app (“any authenticated user can read every other user’s invoice — name, billing address, and card last-four — by incrementing one integer”). Concrete impact is what stops an engineer from filing the bug under theoretical-pentester-noise; it ties the vulnerability to data and damage they recognize.

Severity is a prioritization signal, and its job is consistency. Use a defined scale — CVSS for catalogued CVEs, a qualitative likelihood × impact rating for logic bugs — and attach a one-line justification you’d defend in the readout. The most common writing failure here is severity inflation: marking everything High to make the report look scary. It backfires — when every finding is High, the customer can’t tell the metadata-credential SSRF from the missing security header, and your real critical drowns. Calibrated severity is what makes the report usable as a work queue.

Remediation has to fix the root cause, not the symptom. “Sanitize the input” is the canonical bad fix — it’s advice, not a change, and it often patches the wrong layer. The good remediation names the actual code-level change: for an IDOR, scope the query to the caller (WHERE id = ? AND owner_id = ?, enforced server-side), not “add validation.” A remediation an engineer can paste-and-adapt is worth ten paragraphs of background.

Writing for the engineer, not the hacker

The hardest shift for a strong tester is realizing the report is a handoff document, and the recipient doesn’t share your context. Three habits separate a finding that closes from one that festers. First, write expected vs actual for every reproduction step — it’s the single highest-leverage sentence, because it makes the violation undeniable and self-checking. Second, never bury the lede: lead with the one-line summary (what + impact + severity), then the detail, because the engineer triaging fifty findings reads the first line of each and budgets from there. Third, make remediation copy-able — point at the exact handler and the exact change, and where you can, link the relevant control (e.g. the WSTG test that maps to it) so the fix is verifiable.

A worked finding vs a bare label

Take the Hook’s IDOR. The bad version is one line: “High — IDOR on invoices.” The finding version reads: Summary — any authenticated user can read any other user’s invoice by changing the id (High). Reproduction — log in as test account B, send GET /api/invoices/{A_invoice_id} with B’s session, observe a 200 returning account A’s invoice (name, billing address, card last-four); expected 403. Impact — full read access to every customer’s PII and partial card data across the tenant, exploitable by any logged-in user with no special privilege. Severity — High: trivial to exploit (URL-editable integer), high-value data, broad blast radius. Remediation — enforce ownership server-side on the actual record: change the query to WHERE id = ? AND owner_id = ? (or an equivalent authorization check) on this and every object-by-id handler; deny by default. One of these closes in a day; the other is an opinion.