Notes, evidence, and the harness

The finding you spot at hour two is worthless at hour six if you cannot reproduce it, and worthless in the report if you cannot prove it. Note-keeping is not admin overhead; it is what turns a fleeting observation into a defensible finding. This lesson is what to record, and how, while you work.

Why notes decide outcomes#

Three things go wrong without good notes, and all three cost you findings:

• You cannot reproduce it. You saw something odd, moved on, and now cannot remember the exact request that triggered it. A bug you cannot reproduce is a bug you cannot report.
• You repeat yourself. Without a record of what you tested, you re-test the same endpoints and never reach the untested ones, the opposite of the coverage the last lesson demanded.
• Your report is thin. At write-up time you are reconstructing from memory instead of copying from evidence, so the report is vaguer and less convincing than the work deserved.

Good notes fix all three, and they double as the coverage record that lets you honestly say what you tested.

What to capture, as you go#

Keep a running log, not a memory. For the assessment as a whole:

• The target and scope, pasted verbatim, with the date. What is in, what is out.
• The map: hosts, apps, roles, and the input points you found, your test plan, ticked off as you cover it.
• Your accounts: the two-account harness's credentials and, critically, which objects each account owns (Alice owns orders 1001–1005; Bob owns 2001–2005), so a cross-account result is instantly meaningful.
• What you tested and the result, even the negatives, "tested all account endpoints for IDOR with the two-account swap; only /invoices leaked" is exactly the coverage statement a report needs.

For each candidate finding, capture the moment you see it:

• The exact request that triggers it, full raw HTTP, method, path, headers, body, not a paraphrase. Save it from your proxy.
• The exact response that proves it, or the observable tell (the timing, the changed content, the other user's data).
• Which account you were, and why the result is a boundary crossed.
• A screenshot if the proof is visual, and the timestamp.

Evidence that reproduces#

The test of your evidence is simple: could a stranger reproduce the bug from your notes alone, without you explaining anything? That is exactly what a triager or an exam grader has to do. So your evidence should be copy-pasteable and self-contained:

• Raw requests (from Burp/curl) beat prose descriptions, the reader can replay them.
• Two-account proofs are spelled out: "as Bob (session B), request Alice's object 1001; response returns Alice's data", the whole finding in two requests.
• Command output for server-side bugs: the id/whoami response, the callback your listener received, the file contents read.
• Minimal, benign proofs, per the honesty gate: the one request that demonstrates it, not a destructive rampage.

A lightweight structure that works#

You do not need heavy tooling. A single markdown file per engagement, with sections, Scope, Map, Accounts, Tested, Findings, carries a whole assessment. Many testers use a note app or a dedicated tool, and an intercepting proxy's project file stores the raw requests. This platform's own hunt-notebook approach captures the same idea: the application model, the invariants you believe, the hypotheses you are testing, and the experiments you ran. Whatever the format, the discipline is: write it now, while the request is in front of you, not later from memory.

Notes protect you, too#

On a real engagement or bug bounty, your notes are also your record of having stayed in scope and tested responsibly: what you touched, when, and with what gentle proof. If a client asks "did you cause this outage?", a timestamped log of read-only requests is your answer. Notes are evidence in both directions, for the finding, and for your own conduct.

Where this goes next#

Everything so far assumes you are allowed to be doing this. The next lesson is the line that assumption depends on: scope, permission, and the honesty gate, the difference between security research and unauthorised access, and the rules that keep your work legitimate.