How to Redact PII and Secrets From Bug Report Evidence

Rich bug reports are more reproducible bug reports — the more state you attach, the less time a developer spends guessing. But that same state is exactly where sensitive data hides. A helpful report and a data leak are often the same capture; the difference is whether you redacted it. This guide covers what leaks, where it hides, and how to strip it without gutting the evidence.

What sensitive data hides in a bug report?

Two categories, both worth redacting for different reasons:

• Secrets — credentials that grant access: bearer/JWT tokens, API keys, session cookies, OAuth codes, and passwords. An exposed secret is an active risk: anyone who reads it can act as the user or the app until the secret is rotated.
• PII — data that identifies a person: names, emails, phone numbers, addresses, government IDs, and payment details. Exposure here is a privacy and compliance problem rather than an access one, but it still doesn't belong in a ticket that dozens of people and third-party integrations can read.

The trap is that neither category is visible in the part of the report you're looking at. You screenshot a broken checkout button; the network tab underneath it carries the customer's full card payload and your Stripe session cookie. Redaction is about the parts of the capture you aren't looking at.

Where secrets leak: headers, URLs, console, screenshots, and storage

Five places account for almost all leaks in a browser-captured bug report:

1. Request and response headers. The Authorization header carries bearer tokens and Basic-auth credentials; Cookie and Set-Cookie carry live session identifiers; custom headers like X-API-Key carry keys. A session cookie is a password that never gets typed.
2. URLs and query parameters. Password-reset links, magic-login links, OAuth callbacks, and pre-signed download URLs put tokens directly in the address: ?token=, ?access_token=, ?code=, ?sig=. URLs get logged, indexed, and pasted more freely than anything else.
3. Console logs. Debug logging that dumps a full request or response object — console.log(response) — prints the token and the PII right into the console the bug tool captures.
4. Screenshots. Whatever is on screen: a revealed password field, a table of user emails, a card number mid-entry, an account menu with the user's real name.
5. Browser storage. localStorage and sessionStorage commonly hold JWTs and refresh tokens; any capture that snapshots storage grabs them.

HAR files deserve a special warning: a HAR is a complete recording of every request, with all headers, cookies, and bodies included by default. It's one of the most useful bug artifacts and one of the leakiest — see our guide on capturing a HAR file for a bug report before you attach one.

How to redact PII and secrets from a bug report

Work through the capture in this order — headers first, because they're the highest-value leak:

1. Strip auth headers. Remove or mask Authorization, Cookie, Set-Cookie, and any X-*-Key / X-*-Token header. Replace the value with a placeholder like [redacted] rather than deleting the field, so the developer still knows the header was present.
2. Scrub URL parameters. Mask the values of known-sensitive params (token, access_token, id_token, code, sig, signature, email, key) in every captured URL, including redirects and referrers.
3. Filter console and body content. Redact JSON fields whose key names signal sensitivity — password, token, secret, ssn, card, cvv, email, phone — in request bodies, responses, and logged objects.
4. Mask screenshots with solid boxes. Draw fully opaque rectangles over sensitive regions, or crop them out. Do not rely on blur or pixelation for text (see the FAQ below).
5. Snapshot storage last. If you're capturing localStorage/sessionStorage, redact token-shaped values there too — this is where refresh tokens live.

Prefer an allowlist over a denylist

The denylist above — "redact these known-sensitive fields" — is the pragmatic starting point, but it has a structural weakness: you can't enumerate every sensitive field, and the one you forget is the one that leaks. Where you can, invert it: allowlist the fields you keep and drop everything else by default. Capturing only status, method, url-path, and timing from each request — instead of the full payload — gives a developer most of the diagnostic value with a fraction of the exposure. Denylists fail open; allowlists fail closed.

Automating redaction at capture time

Manual redaction is necessary but unreliable — it depends on a busy person remembering to check five places on every report, and it can't happen at all when the reporter is a customer or a non-technical teammate. The durable fix is to redact where the data is captured, automatically:

• Apply header and parameter rules by default, so Authorization, Cookie, and token params never enter the capture in the first place.
• Redact before upload, not after. The value should never leave the browser in the clear — cleaning it up in the tracker afterward is closing the door after the token walked out.
• Make it the same for everyone. A customer filing a bug should get the same redaction a QA engineer does, because they're the least equipped to do it by hand.

This is the model behind Klavity Snap: it captures the console, network, and environment state a developer needs to reproduce a bug, with sensitive headers and token parameters redacted at the point of capture rather than left for someone to catch later. The goal is the same either way — the report should carry enough state to reproduce the bug and nothing that could be used to break in.

What to do if a secret already leaked into a ticket

If a live token, key, or cookie made it into a bug tracker, treat it as compromised — because it was readable by everyone with access, and possibly by integrations and bots too. In order:

1. Rotate the credential first. Issue a new secret and revoke the old one. This is the only step that actually closes the exposure; everything else is cleanup.
2. Remove it from the ticket. Edit the comment or delete the attachment — but know that many trackers keep edit history, and notifications may have already fanned the value out by email and chat.
3. Check for propagation. Look at the tracker's audit log, connected integrations, and any mirrored channels to gauge how far the value traveled.
4. Tell the owner. Notify whoever owns that secret or that user's data so they can watch for misuse.

Deleting without rotating is the common mistake: it hides the secret but doesn't invalidate it. If you only do one thing, rotate.

The bottom line

A good bug report is a detailed one, and detail is where secrets and PII hide. You don't have to choose between the two: strip auth headers and token parameters, mask screenshots with solid boxes instead of blur, prefer allowlisting the fields you keep, and do all of it at capture time before anything leaves the browser. Redaction that depends on human memory eventually fails; redaction built into the capture doesn't. For more on capturing evidence safely, see the Klavity blog.