Home › Guides › Redact logs before sharing
Redact logs before sharing
Direct answer: assume every log contains secrets until checked: authorization headers, session IDs in URLs, API keys in startup config, emails, IPs, and card numbers. Run the redactor below for the known shapes, then apply the delete-don't-redact rules for whole sensitive lines, then read the result once before it leaves your machine.
Redact this excerpt now
Redacted output
What was replaced
| Pattern class | Replacements |
|---|
Redaction is pattern-based: it catches known secret shapes (keys, tokens, cards that pass a checksum). It cannot catch a secret in an unusual shape — read the output once before sharing.
The checklist, in the order leaks actually happen
- Authorization & cookie headers.
Authorization: Bearer …,Basic …,Cookie:,Set-Cookie:. A bearer token in a public issue is a live credential. - Session IDs and tokens in URLs.
?sessionid=,&token=, password-reset links. URLs get copied furthest. - Startup/config dumps. The first lines of many logs helpfully print the environment: keys, DSNs with passwords, webhook secrets.
- Key=value secrets under any name. password, passwd, api_key, client_secret, access_token — plus bare shapes that need no name: JWTs (
eyJ…) and cloud keys (AKIA…). - People data. Emails, phone numbers, IPs, and anything in a user object your app logged for debugging.
- Payment data. Card numbers (the redactor only masks checksum-valid ones, deliberately — order numbers survive).
Delete, don't redact
Some lines should not travel at all: full request/response body dumps of auth endpoints, password-reset emails quoted in logs, private keys (even the header line announces you have one), and any line whose redacted version would be entirely placeholders — it carries no diagnostic value, only risk. Deleting whole lines is also the honest answer for secrets in shapes no pattern catches.
The final read
Pattern redaction plus the checklist still ends with a human read of the actual output — a minute of skimming for anything that looks like a credential, an address, or a customer's name. That read is not a formality: it is the only step that can catch the secret your application invented a new format for. The same discipline is built into every tool on this site — board samples and exports are redacted by default, as the privacy page spells out.
Frequently asked questions
What is the single most common secret leaked in shared logs?
Authorization headers, because they ride along inside otherwise innocent request dumps — followed closely by session IDs in URLs (they get forwarded, screenshotted and indexed) and startup lines where someone logged the loaded config, keys included. If you only check three things, check headers, URLs, and the first fifty lines of the file.
Is it enough to search for "password" before sharing?
No. Secrets hide under many names (token, secret, api_key, Authorization, sessionid, set-cookie) and many shapes (JWTs and cloud keys don’t contain the word "key" at all in the value). A pattern-based pass like the redactor here covers the known shapes; the checklist below covers placement — which lines to simply delete rather than redact.
Should I redact IP addresses? They’re not secrets.
They are personal data in many jurisdictions, and in a shared log they identify your users or your infrastructure. The default here is to mask them. The exception is a private incident channel with your own team where IPs are the evidence (abuse investigation) — then share the unredacted file through the private channel, not a public ticket, and say so in the ticket.