Start with secrets and authentication data
Search for Authorization, Bearer, token, secret, password, cookie, session, api_key, client_secret, database_url, and connection_string. Also look for vendor-specific prefixes and long random values.
Do not preserve a few visible characters of a live secret unless your security process explicitly permits it. A fully replaced [SECRET] value is safer for public examples.
Remove customer and employee identifiers
Logs may include email addresses, usernames, account IDs, order numbers, IP addresses, request bodies, query strings, and user-entered text. Replace them consistently so the sequence of events remains understandable.
Be especially careful with bulk logs. A single export may contain information for many users, not only the user connected to the visible error.
Preserve debugging value
Keep the exception type, message, package versions, status code, request method, safe timestamps, and relevant stack frames. Remove unrelated entries and repetitive noise.
If a path is useful, replace the user-specific part. For example, change /Users/alice/private-project/file.js to /Users/[USER]/[PROJECT]/file.js.
Respond to actual exposure
Sanitizing a future copy does not secure a credential already posted in a ticket, chat, repository, or AI prompt. Revoke or rotate it and inspect access logs when appropriate.
Document where the value was shared and follow your incident process. Deleting a message may reduce visibility but should not be treated as credential rotation.
Final review checklist
- Credentials and cookies are fully removed
- Request and response bodies are checked
- User paths and internal hosts are masked
- Only the relevant time window remains
- Exposed secrets have been rotated