Redacting screenshots for a bug bounty report

A bug bounty screenshot has a harder job than an internal one. On an engagement you send evidence to a client who already owns the systems in it. On a bounty you send it to a third-party platform, a triager you have never met, and — if the report is disclosed after the fix — eventually the public.

That changes the calculation. The question is no longer "does the client need to see this", it is "am I comfortable with this being read by people I cannot name, possibly forever".

Two pressures pulling opposite ways

A report that redacts too little leaks. A report that redacts too much gets closed as not reproducible, which is the most common way a real finding dies.

The resolution is that these pull on different things. Triagers need the mechanism: the request, the parameter, the response that proves the behaviour, and enough of the impact to grade severity. They do not need your session cookie, your account email, or the personal data of whoever else's record you happened to pull. Redacting the second set costs the report nothing.

What must not leave your machine

Your own session tokens and cookies. A live token in a screenshot is a live token in someone else's ticket queue. See below — redaction is not the primary control here.
Your account identifiers. The email you registered with, your user ID, your API key for the target. Researchers routinely reuse an address across programs; leaking it links your accounts.
Other users' data. If the bug is an access-control failure, you have almost certainly touched a real person's record. See the next section.
Anything from outside the program's scope. Other tabs, other targets, another program's subdomain in your history. Scope violations are visible in screenshots and they are held against you.
Your own machine. Local paths carry your username, the browser chrome carries your bookmarks and open tabs, the system tray carries your VPN.

When the bug exposes someone else's data

This is the case that deserves its own rule, because the instinct — screenshot the evidence — is wrong.

Capture the fact, not the data. To prove an IDOR you need to show that a request for an identifier you do not own returned a record. You do not need the record. One row, with every field redacted except the identifier that proves it is not yours, demonstrates the vulnerability exactly as well as fifty rows of real names and addresses — and it is the difference between reporting a data exposure and creating a second one.

Pull the minimum. Do not enumerate to show scale; describe the scale in text and let the triager verify it themselves on systems they own.

Most program policies say some version of this explicitly. Read the one you are submitting to before you decide, because it is the document you will be judged against.

What a good proof-of-concept screenshot actually contains

Redaction is easier when there is less in the frame, and the way to get less in the frame is to know what the triager is looking for. For most web findings that is a request and its response, side by side, showing three things: the identifier or parameter you changed, the response proving the server accepted it, and a status code or body fragment that makes the impact obvious.

Everything else is decoration. The full response body, the complete header block, the whole proxy window with its history pane listing every other host you touched — none of it strengthens the report, and each carries its own leak. A cropped request/response pair with two values highlighted is both a better report and a smaller redaction problem.

One caveat on screen recordings, which some programs prefer for complex chains: a video is a much harder redaction problem than a still, because every frame is a separate capture and a value can flash on screen for a fraction of a second. Blackbar does not redact video, and no still-image tool does. If a recording is required, plan the run first — clean profile, dedicated test accounts, rotated credentials — because there is no reliable pass afterwards.

Rotate, do not redact, anything live

Redaction is a control that can fail. For a value that is currently valid — your session token, an API key you were issued, a password you set on a test account — a failed redaction is not an embarrassment, it is a compromise.

So invalidate first: log out to kill the session, rotate the key, change the test-account password. Then the screenshot contains a dead string and the redaction is defence in depth rather than the only thing standing between you and an incident.

Write it as if it will be public

Many programs disclose reports after remediation, sometimes years later, and disclosure is frequently the platform's or the vendor's decision rather than yours. Attachments are stored on the platform regardless, and editing a report afterwards does not reliably remove a file that has already been uploaded — assume the first version you submit is the version that persists.

The practical form of this: redact at submission time, not at disclosure time. There is no disclosure-time pass, because by then the file has been sitting in a ticket for months.

A pass that takes two minutes

Capture in a clean browser profile — no other tabs, no bookmarks bar, no extensions, not signed into anything unrelated.
Let automatic detection take the structured values: tokens, keys, JWTs, authorisation headers, emails, IP addresses.
Do a manual pass for the things no detector can know — your username in a path, an internal ticket number, a customer name in a record.
Confirm the redaction destroyed the pixels rather than covering them, and that the export is a new file with metadata stripped.
Grep the exported file for the values you just redacted. If any come back, the bar is decorative.

strings poc.png | grep -iE "sessionid|bearer |eyJ|@gmail|@your-domain"
exiftool poc.png | head -40

One thing worth saying plainly

Nothing above is legal advice, and none of it overrides the program you are submitting to. The scope, the disclosure policy and the data-handling rules in that program's brief are the authority. This is the operational layer underneath them: assuming you have decided what you are allowed to capture, this is how you avoid shipping more than you meant to.