2026-07-14 · 5 min read · Rahul Chitturi
- json
- logs
- security
Production logs are often the fastest way to explain a bug, but they are also where bearer tokens, emails, account IDs, raw payloads, and stack traces get copied into tickets. Redaction should make the log safe to share without destroying the shape that engineers need for debugging.
Start by formatting the JSON so nested fields are visible. It is easier to mask a token, payload, or customer identifier when you can see exactly where it sits in the request, response, or structured log event.
Mask values while preserving shape
The safest redaction keeps field names, types, and lengths meaningful while replacing sensitive values. That lets reviewers see whether a field was present, empty, repeated, or malformed without exposing the actual secret.
- Replace bearer tokens, session IDs, API keys, and cookies with stable placeholders
- Mask emails and user IDs consistently so relationships remain visible
- Preserve array lengths, object nesting, and null versus missing fields
- Remove stack frames that expose private paths only after recording the error type
Compare before and after redaction
Redaction itself can introduce confusion if it changes types or removes the field that caused the bug. Diff the original local copy against the sanitized version and confirm the debugging signal remains: status code, failing field, timestamp, correlation ID, and relevant headers.
If a field contains Base64 or JWT content, decode only safe samples or synthetic values. The decoded shape may reveal claims or nested JSON that need their own redaction pass.
A Flashman workflow
Use the JSON formatter to make structured logs readable, the JWT and Base64 tools to inspect safe sample wrappers, and the diff tool to review the sanitized version before sharing it.
Keep the original log local and share only the redacted fixture. A good fixture should reproduce the parser, validation, or contract problem without granting access to a user account or internal system.