Avoid Secret Or Private Log Context

avoid-secret-or-private-log-context

Summary

Diagnostics can outlive their request and move through systems with different access rules. Record safe identifiers and classifications at the boundary that understands data sensitivity, using explicit protected workflows for rare sensitive evidence.

Problem

Logs, traces, metrics, error reports, and agent transcripts can outlive the request that produced them and move through systems with different access rules. Including secrets, tokens, raw payloads, private user data, or proprietary context can turn diagnostics into a data leak.

Preferred Move

Log stable identifiers, classifications, counts, error kinds, and correlation IDs instead of raw secret or private values. Redact, hash, tokenize, or omit sensitive context at the boundary that knows the data classification.

Tradeoff

Some incidents require sensitive evidence. Capture it only through an explicit, access-controlled workflow with retention and audit expectations. Do not smuggle sensitive data into ordinary logs because it is convenient during debugging.

Agent Instruction

When adding diagnostics, classify the context before recording it. Avoid logging secrets, tokens,
raw private payloads, connection strings, source code, or user-sensitive fields; prefer safe
identifiers and redacted summaries.

Examples

Bad: the log stores the credential-bearing header.

warn!(
    authorization = %request.authorization_header(),
    "request rejected by auth middleware",
);

Good: the log records the decision and correlation fields without the secret.

warn!(
    request_id = %request.id(),
    auth_scheme = %request.auth_scheme(),
    reason = "expired_token",
    "request rejected by auth middleware",
);

References

Source Use Note
OWASP data to exclude supports Sensitive values should be removed or protected.
OWASP logging vocabulary adapts Security events need useful but safe context.