Logging Sensitive Data
Logging sensitive data writes passwords, tokens, and PII into logs that spread to aggregators and backups beyond the source's access controls, breaching privacy rules. Classify data, redact sensitive fields automatically in structured logging, and rotate anything exposed.
Logging sensitive data is the practice of writing secrets and protected information — passwords, API keys, session tokens, full credit-card numbers, government IDs, health data, other PII — into application logs. Logs feel ephemeral and internal, but they are copied to aggregation platforms, shipped to third-party services, retained for months, and backed up, so anything logged escapes the access controls that protect the source data.
Why It Happens
During debugging it is natural to log a whole request, response, or object to see what is happening, and that dump includes sensitive fields. Verbose logging added to chase one bug stays in production. Error handlers log full payloads. Third-party SDKs and frameworks log request details by default. No one classifies which fields are sensitive, so everything flows through.
Why It Hurts
Logs are widely accessible — to developers, operators, support, and the log platform's own staff — far more broadly than production databases. They are forwarded to SaaS log services, indexed for search, and kept in backups, multiplying the copies of any secret. A token in a log is a live credential anyone with log access can use. PII in logs violates GDPR, HIPAA, PCI-DSS (which forbids storing full card data and CVV), bringing fines and breach obligations. Because logs persist, the exposure is durable and easy to overlook.
Warning Signs
- Full request/response bodies or headers (including
Authorization) are logged. - Tokens, passwords, or card numbers appear in log search results.
- Debug logging dumps entire objects containing user data.
- There is no policy or tooling defining what must never be logged.
Better Alternatives
Classify data and define explicitly what may never be logged. Use structured logging with field-level policies that redact or mask sensitive attributes automatically (e.g. show last four digits, hash identifiers, drop secrets entirely). Apply redaction at the logging layer so it is not left to each call site. Strip Authorization and Cookie headers and known sensitive keys before emitting. Minimize log retention and restrict access to log platforms. Treat any secret that has been logged as compromised and rotate it.
How to Refactor Out of It
- Search logs and code for sensitive values and the call sites that emit them.
- Classify fields (secrets, PII, payment data) and document a never-log list.
- Add automatic redaction/masking in the logging framework keyed to that classification.
- Remove blanket request/response/object dumps; log identifiers, not payloads.
- Restrict access to and retention of logs, and scrub historical logs where feasible.
- Rotate any credentials that were exposed in logs, and add tests asserting sensitive fields are redacted.