Logging Sensitive Data (Pitfalls and Redaction)

What Must Never Appear in Logs

• Passwords, access tokens, refresh tokens, API keys
• Authorization headers, session cookies
• Full payment details, full ID numbers
• Private keys, signing material

Safe Logging Strategy

• Log identifiers (request_id, user_id, session_id hash) not secrets.
• Use allowlist logging: explicitly pick fields to log.
• Redact at a single choke point (logger middleware), not ad-hoc.

Redaction Pattern

# Replace sensitive keys anywhere in structured payloads
REDACT_KEYS = ["authorization", "cookie", "password", "token", "secret", "api_key"]
# If key matches: value = "[REDACTED]"

Production Validation

# Search for likely secret patterns (examples; adapt)
# Do this in a secure environment with access controls
egrep -R "Bearer " /var/log/app/ 2>/dev/null | head -20
egrep -R "api_key|refresh_token|password=" /var/log/app/ 2>/dev/null | head -20

Failure Modes

• Debug logging in prod: leaks request bodies. Enforce config guardrails.
• Exception dumps: frameworks log headers by default. Override defaults.
• Third-party SDKs: may log request payloads. Pin versions, review settings.

Incident Query Playbook

If leak suspected:
1) Identify time window and deployments
2) Search logs for token prefixes, auth headers, cookie names
3) Rotate affected secrets/tokens
4) Add regression test: redaction unit test + integration log scan