Screenshot Proofs That Actually Help Bug Bounty Reports
Screenshots do not replace a reproduction. They support it. A blurry full-screen PNG of your IDE proves you were busy. It does not prove impact.
Good evidence answers one question per frame: what changed, for whom, and where in the app?
Show the address bar and the identity
Crop tightly, but keep the URL visible. If the bug is cross-account, show which user is logged in — avatar, email fragment, or account switcher — in the same frame as the leaked data. A random table of names with no context looks like a staging seed file.
For API bugs, a response screenshot alone is weak. Pair it with the request: method, path, and the parameter you changed. Burp's copy-as-image or a short annotated Repeater export beats three overlapping windows fighting for attention.
Timestamp and request-id / cf-ray headers help when the program has multiple edges. Paste those IDs in the report text too; intake portals compress images until text becomes mush.
Dark mode vs light mode is not a style debate. Pick whichever keeps contrast high after upload. Thin gray-on-gray JSON in a 4K capture becomes unreadable when the portal downscales it.
Redact like you mean it
Mask real customer data, session tokens, and unrelated inbox content. Leave the canary visible. If you used victim+canary4821@yourdomain, that string should remain readable so triage can search logs.
Do not black-box half the screen so aggressively that the vulnerability disappears. Soft blur on faces and emails; keep object IDs you own. If a token must appear for proof, truncate the middle and state that the full value was rotated after testing.
Watch the edges of the crop. Autofill dropdowns, Slack sidebars, and password managers love to leak into "clean" shots. I've had to re-shoot because a second monitor showed another program's private report title.
Prefer short clips for timing bugs
Click-race and TOCTOU issues die in stills. A 10–20 second screen recording with the system clock visible, or two frames labeled T0 / T1, communicates order. Keep files small; huge MP4s bounce off intake forms or sit in malware scanners forever.
Annotate sparingly. One arrow and a five-word caption beat a rainbow of rectangles. Triagers skim. If you need ten arrows, your still is trying to tell a story that belongs in numbered steps.
For stored XSS or cache poisoning, show the priming request and the later hit from a clean client. Same canary, different session. That pair is the whole argument.
What not to attach
- Your password manager autofill dropdown
- Slack DMs celebrating the find
- Ten near-identical 4K monitorshots of the same 200 OK
- Proof that includes another researcher's report ID or private program data
- Raw HAR files full of live cookies unless the program explicitly asks
End with a one-line index in the report: "Figure 1: account A settings; Figure 2: account B viewing A's canary." People reopen attachments out of order. Make the order obvious.
Evidence is a courtesy to the human who has fifty other queues open. Make theirs easy.