Encrypt Online

How to Remove Secrets From Logs Before Sharing

A practical guide to redacting tokens, cookies, API keys, and .env values before you paste logs into tickets, chat, or incident docs.

Encrypt Online Editorial Team3 min readProtect & Encrypt
How to Remove Secrets From Logs Before Sharing guide cover

Tip

Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.

The dangerous moment is rarely the production request itself. It is the screenshot, support ticket, Slack paste, or incident document created five minutes later with more sensitive material than the sender realizes.

Good log sharing means removing secrets while keeping enough structure to debug the real problem.

What should never leave the log

  • API keys, bearer tokens, session cookies, and refresh tokens
  • Authorization headers and signed webhook secrets
  • Database passwords, .env values, and connection strings
  • Full email addresses, phone numbers, or customer identifiers if the ticket does not need them

Before / after example

JSON
{
  "authorization": "Bearer sk_live_51N...",
  "cookie": "session=eyJhbGciOi...",
  "db_password": "Trunk-Bridge-28",
  "path": "/admin/export?id=8472"
}
JSON
{
  "authorization": "Bearer [REDACTED]",
  "cookie": "[REDACTED]",
  "db_password": "[REDACTED]",
  "path": "/admin/export?id=8472"
}

Packages and libraries that help

  • Node.js: pino supports built-in redact rules, and fast-redact is useful when you need explicit path-based masking.
  • Python: use a custom logging.Filter, a structlog processor, or hmac.compare_digest style helpers only after you remove secret-bearing fields from the debug output.
  • Go: prefer structured logging with field allow-lists in zap, zerolog, or slog adapters instead of dumping whole request objects.
  • Ruby / Rails: config.filter_parameters already solves a lot of accidental leak cases if it is kept current.

Where this breaks

  • Redacting only visible keys like password while leaving Authorization, cookie, token, secret, or .env blobs intact.
  • Copying raw logs into Markdown or chat before running the redaction step.
  • Using regex-only masking without checking nested JSON, arrays, or multiline values.
  • Forgetting that secrets also appear in URLs, headers, stack traces, and environment dumps.

Where the tool helps

  • Use Secret Redactor first when you need a browser-side pass that strips obvious tokens, cookies, headers, and .env patterns before the log leaves your machine.
  • Use JSON Format or YAML Formatter after redaction when nested payloads still need cleanup for readability.
  • Use Text Compare to confirm that your redacted version removed secrets without deleting the lines the recipient still needs for debugging.

Questions that settle the decision

Should I mask or delete the field?

Usually mask the value and keep the field name so the debugging context survives. Delete the entire field only if the key name itself is sensitive.

Can I trust manual find-and-replace?

Only for tiny one-off cases. Repeatable redaction rules inside the logger or exporter are safer because they run before the log leaves the system.

Developer workflow

Use this guide as a local handling check before a secret or protected file leaves your machine.

  1. Start with a harmless value that has the same shape as the real secret.
  2. Run the matching browser tool and copy the result into a scratch note.
  3. Run the decrypt, restore, or verification step before you share the real output.
Text
1. disposable input
2. browser-only protect/encrypt step
3. decrypt or restore check
4. share only the intended artifact

References

Report a correction