How to sanitize logs before you share them

Where shared logs end up

• Public issues and forums are indexed by search engines and read by bots that look for keys.
• Vendor support tickets live in someone else's helpdesk, with their staff, retention and security.
• Team chat is searchable by everyone in the channel, including people who join later, and synced to phones.
• AI assistants store the conversation on the provider's servers.

Deleting the message later does not undo it. A copy may already sit in an email notification, a search index or a backup, and a leaked key keeps working until you revoke it.

What to remove

• Configuration printed at startup: environment variables, connection strings, API keys.
• HTTP debug output: Authorization headers, cookies, tokens in query strings.
• Private keys and certificates.
• Customer data in error messages: emails, IP addresses, card numbers, phone numbers.
• Internal details you may not want public: hostnames, account IDs, file paths with user names.

Example: a startup log before and after

Before highlights what PasteSafe finds. After is its exact output.

2026-09-15 09:41:07 INFO  starting billing-api on db-prod.acme.internal with config:
  DATABASE_URL=postgres://billing:Wint3r-Fake-Pass@db-prod.acme.internal:5432/billing
  STRIPE_SECRET_KEY=sk_test_51FakeKeyForDocs0nlyNotReal0000
  AWS_ACCESS_KEY_ID=AKIA2EXAMPLE7FAKEKEY
  SENTRY_ENVIRONMENT=production
2026-09-15 09:41:09 DEBUG POST https://api.example.com/v1/charges
  Authorization: Bearer FakeBearer7fK2mZpL9wR3nB8vT1yCq
  Cookie: sessionid=9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c; theme=dark
2026-09-15 09:41:09 ERROR 402 card_declined for ops@example.net from 198.51.100.7

2026-09-15 09:41:07 INFO  starting billing-api on db-prod.acme.internal with config:
  DATABASE_URL=postgres://billing:DB_PASSWORD_1@db-prod.acme.internal:5432/billing
  STRIPE_SECRET_KEY=STRIPE_KEY_1
  AWS_ACCESS_KEY_ID=AWS_ACCESS_KEY_1
  SENTRY_ENVIRONMENT=production
2026-09-15 09:41:09 DEBUG POST https://api.example.com/v1/charges
  Authorization: Bearer BEARER_TOKEN_1
  Cookie: sessionid=9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c; theme=dark
2026-09-15 09:41:09 ERROR 402 card_declined for EMAIL_1 from IP_1

The keys, the database password, the Bearer token, the email and the client IP are replaced. The internal hostname and the session cookie are not: PasteSafe does not treat hostnames as secret, and a sessionid cookie with a hex value, sent together with other cookies, matches none of its rules. That is why the last step below is to read the result.

Step by step with PasteSafe

1. Cut the log down to the part that matters. grep -n -B 5 -A 30 ERROR app.log prints each error with 5 lines before it and 30 after. Less text means less to leak.
2. Paste it into PasteSafe or drop the file onto the editor.
3. Look through the Findings list, which groups what was masked by type.
4. Read the cleaned text and replace anything left by hand, like the hostname and cookie above.
5. Press Copy cleaned text and paste it where it needs to go.

On the command line

gitleaks, the open source scanner whose rules PasteSafe uses, can check a log for known secret formats. It reports what it finds and does not change the file:

gitleaks dir -v app.log
cat app.log | gitleaks -v stdin

To replace values in a file, sed handles simple key=value cases:

sed -E 's/((password|secret|token|api_key)=)[^&[:space:]]+/\1REDACTED/g' app.log > app.clean.log

A pattern list like this only catches the names you wrote down. Run gitleaks on the cleaned file afterwards to see what is left, and read it anyway.

What PasteSafe does not catch

• Internal hostnames, account IDs and file paths.
• Session cookies in a Cookie header with several cookies, when the name ends in id, like sessionid or session_id, or the value is plain hex.
• Passwords typed as plain words in a message, and names or street addresses.