Writing a finding a client can fix

A finding is not a trophy. It is a decision aid for someone who has to fix the problem, prioritise it against other work and prove it is resolved.

The structure

1. Title — a short, specific description.
2. Severity — with the reasoning, not just a score.
3. Affected asset — the exact system, URL or account.
4. Evidence — request/response, screenshot, log or command output.
5. Impact — what an attacker could do and what it means to the business.
6. Likelihood — who could exploit it and under what conditions.
7. Remediation — the specific change, plus verification steps.
8. References — standards or guidance, if useful.

Separate the technical from the business

An engineer needs the request and the reproduction. A manager needs to know whether customer data, money or availability is at risk. Write both, clearly labelled.

Bad: "The application is vulnerable to IDOR."

Better: "An authenticated customer can read any other customer's invoice by changing the invoice ID in /api/invoices/{id}. This exposes names, addresses and amounts for every customer."