How to Sanitize Logs: A Practical Guide to Removing Sensitive Data

A log's job is to record what happened. It doesn't distinguish between "this is useful context" and "this is a password someone typed into a failed login attempt" - it just writes down whatever passed through the code path being logged. Sanitizing a log is the step where a human (or a tool) draws that line before the log goes anywhere else.

Why logs end up holding sensitive data

Nobody sets out to log a password. It happens indirectly, usually through one of these paths:

• A broad logging statement that dumps an entire request or response object, headers included
• An error handler that logs the full exception context, which happens to include the input that caused it
• Debug-level logging left enabled in production
• A third-party library that logs more than expected by default

What typically shows up in logs

Before and after: what sanitizing actually looks like

Before:
2026-03-01T14:22:03Z ERROR checkout failed for user
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0
[email protected] card=4111111111111111 status=502

After:
2026-03-01T14:22:03Z ERROR checkout failed for user
Authorization: Bearer ***************
email=j***@example.com card=[REDACTED] status=502

Notice what stayed exactly the same: the timestamp, the log level, the error message, and the status code. Those are what someone actually needs to diagnose the checkout failure - none of them required the card number or the full token.

Redaction vs. masking

These two approaches solve slightly different problems. Redaction replaces a value completely (card=[REDACTED]), which is safest when the value has no debugging value at all. Masking preserves partial context (j***@example.com), which helps confirm "yes, this is the same user across these log lines" without exposing the full value. Neither is universally correct - pick based on whether partial context genuinely helps whoever reads the log next.

A practical process

1. Identify the destination - an internal Slack thread is lower-risk than a public GitHub issue or a third-party support form; sanitize as if it could end up public either way, since it's cheap to do and removes the guesswork.
2. Scan for credentials first: API keys, bearer tokens, session cookies, database connection strings.
3. Scan for personal data: emails, phone numbers, names tied to identifying context, physical addresses.
4. Check structured logs by field name, not just by value shape - a JSON field like "ssn": "078-05-1120" only reveals itself if you look at the key.
5. Mask or redact rather than deleting lines outright, so the surrounding context (timestamps, request IDs, error messages) survives.
6. Rotate any real credential that was ever visible before this cleanup - sanitizing the copy you're about to share doesn't undo an earlier exposure.

When to sanitize

The honest answer is: every time a log leaves the system that generated it. That includes pasting a snippet into a bug report, forwarding it to a vendor's support team, dropping it into an AI coding assistant, or attaching it to an internal ticket. "Internal" doesn't mean safe - internal tools get indexed, searched, and occasionally exported too.

Centralized logging considerations

If logs flow into a centralized platform (a SIEM, an aggregator, a hosted logging service), sanitization ideally happens at two points: at the source, via logging middleware that redacts known-sensitive fields before they're ever written, and again at the point of sharing, for anything pulled out of that platform and handed to someone else. Relying on the aggregator alone to "clean things up later" means the raw sensitive data already exists in a system you may not fully control the retention of.

Common mistakes

• Redacting only the obviously-named fields ("password") and missing tokens embedded in URLs or headers.
• Deleting entire log lines instead of masking, which can remove the exact context needed to debug the issue.
• Treating a one-time cleanup as sufficient instead of making sanitization a habit before every share.
• Assuming a value is safe because it's inside a cookie or header rather than a labeled "password" field.

Summary

Sanitizing logs is about removing exactly what shouldn't travel - credentials, tokens, and personal data - while keeping everything that actually helps debug the issue. Doing it by hand works occasionally; doing it consistently, especially under time pressure, is what a dedicated sanitizer is built for.