How do I remove an API key from a log without breaking the log's usefulness?

Replace the key with a fixed placeholder like [REDACTED] or mask everything after a recognizable prefix, rather than deleting the whole log line - the surrounding request details usually still matter for debugging.

Is it safe to log the last few characters of an API key?

Generally yes, for identification purposes - most keys have enough entropy that a few trailing characters don't meaningfully weaken them, and it's a common pattern used by providers like Stripe and GitHub themselves.

What should I do if a real API key was already exposed in a shared log?

Rotate it immediately. Removing it from the copy you already shared doesn't undo the exposure, and there's no reliable way to confirm nobody has seen it.

Logs

Published March 9, 20269 min read

How to Remove API Keys, Tokens and Passwords from Logs

Credentials in logs are the highest-stakes category to catch. Here's what to look for and how to redact it correctly.

Credentials are the highest-stakes category to catch in a log, because unlike an email address or an internal hostname, a live API key or token is immediately usable by anyone who sees it. This is a practical, pattern-based guide to finding and redacting them.

What these look like in practice

Type	Typical pattern	Where it shows up
Bearer token	Authorization: Bearer eyJhbGci...	Request/response headers
API key (prefixed)	sk-live-51H..., ghp_..., AKIA...	Headers, query strings, config dumps
Basic auth	Authorization: Basic dXNlcjpwYXNz	Request headers
Session cookie	connect.sid=s%3AabC123...	Cookie / Set-Cookie headers
Password (plaintext)	password=hunter2	Form submissions, request bodies

Before and after

Before:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3F1c
OPENAI_API_KEY=sk-proj-Ab12Cd34Ef56Gh78
password=temporaryPass123

After:
Authorization: Bearer ***************
OPENAI_API_KEY=sk-pr************
password=[REDACTED]

The moment a log with a live credential leaves your controlled systems, you lose the ability to know for certain who's seen it. That applies to every destination a log commonly ends up in:

Ticket systems - support tickets often get forwarded between teams, and some are visible to the reporting customer.
Chat platforms - Slack and similar tools index and retain message history well beyond the original conversation.
Monitoring and observability platforms - third-party SaaS tools that may retain data under their own policies.
Third-party support vendors - if you're debugging with an external provider, the log leaves your organization entirely.
AI coding assistants and chat tools - pasted context can be retained depending on the tool and your settings.

None of these destinations are inherently unsafe, but each one is a place a credential could persist or be seen by someone beyond the original intended audience. Redacting before pasting removes that risk instead of hoping it doesn't materialize.

A pattern-based approach

Scan for the word "Authorization" and mask everything after the scheme (Bearer/Basic).
Scan for known key prefixes specific to the providers you use (sk-, ghp_, AKIA, xox b-, etc.).
Scan for "password", "secret", "token", and "key" as field names in structured logs, and mask their values regardless of whether the value itself looks like a credential.
Scan cookie headers - Set-Cookie and Cookie - and mask the value portion of every cookie, not just ones with obviously sensitive names.
Check query strings for embedded credentials, which are easy to miss since they blend into the rest of the URL.

Log Sanitizer runs all of this automatically against pasted logs - it recognizes provider-specific key formats, Bearer/Basic auth headers, and cookie values, and masks each one while leaving the rest of the log untouched.

Common mistakes

Redacting the Authorization header but missing the same token duplicated in a query string or a retry log line.
Assuming a truncated key display (sk-....abcd) means the full key isn't logged elsewhere in the same file.
Manually find-and-replacing one occurrence and missing repeated instances further down a long log.
Forgetting to rotate a credential that was genuinely exposed, even after cleaning up the shared copy.

Summary

Credentials deserve the most careful handling of anything found in a log, because their impact is immediate and direct. Pattern-based detection - recognizing Bearer tokens, provider key prefixes, and common field names - catches the vast majority of cases that manual review misses under time pressure.

Frequently asked questions

How do I remove an API key from a log without breaking the log's usefulness?: Replace the key with a fixed placeholder like [REDACTED] or mask everything after a recognizable prefix, rather than deleting the whole log line - the surrounding request details usually still matter for debugging.
Is it safe to log the last few characters of an API key?: Generally yes, for identification purposes - most keys have enough entropy that a few trailing characters don't meaningfully weaken them, and it's a common pattern used by providers like Stripe and GitHub themselves.
What should I do if a real API key was already exposed in a shared log?: Rotate it immediately. Removing it from the copy you already shared doesn't undo the exposure, and there's no reliable way to confirm nobody has seen it.

#logs #security #secrets #log-sanitizer #devops