Prevent this by never logging secrets, tokens, session data, credentials, or personal data unless there is a clear need. Review logging code and templates, redact or mask sensitive fields, and restrict log access. Also check exception handlers, debug modes, and third-party libraries, because they often leak request contents, stack traces, or authentication material.
Why logging leaks happen even in well-run systems
Sensitive data usually reaches logs through convenience, not intent. Teams add request dumps, exception traces, or debug output to speed up troubleshooting, then those messages inherit secrets, tokens, cookies, account identifiers, and personal data from upstream code paths. The problem is often amplified by shared templates and libraries that log more than the application owner realises.
Leakage also happens because logging is treated as an observability layer rather than a data-handling surface. A log statement can capture data before validation, after decryption, or inside an error path where the code assumes the message is harmless. Once that output is centralised, retained, and searchable, the exposure becomes durable rather than transient.
For software teams, this is a weak-spot pattern that aligns closely with CWE Top 25 Guide, especially weaknesses involving insertion of sensitive information into log file, debug output, and externally visible error messages. Treat logging as a controlled data sink, not a free-form diagnostics channel.
What to remove or transform before data reaches the logger
The safest rule is to avoid logging secrets, session material, credentials, authentication headers, and unnecessary personal data in the first place. If a field is not needed for incident triage, root-cause analysis, or audit evidence, it should not be present in the log event at all.
When the field is operationally useful but sensitive, transform it before write-time. Redaction is preferable for values that must never be recoverable, while masking or tokenisation may be acceptable for partial correlation where the business need is clear. The key point is consistency: ad hoc masking in one code path will not protect exception handlers, structured logging helpers, or third-party components that emit the same data elsewhere.
Build the control into the logging layer itself, including allowlists for fields, safe serializers, and output filters for common sensitive patterns. That makes the protection harder to bypass than scattered reviewer judgement on individual log statements.
How organisations keep logs useful without creating an exposure channel
Strong log hygiene depends on more than code review. Restrict access to logs so that only people and systems with a clear operational need can read them, and make sure retention is aligned to the minimum useful period. If log data is copied into analytics, SIEM, or support workflows, the same sensitivity rules should follow it.
Operationally, the most common failure points are debug modes left enabled, overly verbose framework defaults, and exception handlers that include raw request bodies or stack traces. Those paths deserve explicit testing because they often bypass the logging conventions used in normal application code. Organisations that rely on cloud-native logging should also verify that ingestion, export, and retention settings preserve the intended redaction behaviour end to end, as highlighted in the Cloud Logging and Audit Trail Guide.
Where services emit logs through pipelines, queues, or managed transfer paths, the controls should extend beyond the application boundary. The Managed File Transfer (MFT) Security Guide is relevant because log exports, support bundles, and audit extracts often become secondary data-sharing channels that need the same scrutiny as primary application output.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | Sensitive data in logs is a logging and error-handling control concern. |
| Recommendation — Filter secrets and personal data from application logs and error output. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | This subject needs controlled event capture and clear logging scope. |
| AU-12 — Audit Record Generation | Log generation must be designed to avoid recording sensitive material. | |
| Recommendation — Define logged events to exclude sensitive fields and unnecessary content. Generate audit records with redaction rules before data is written. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | ISO logging controls directly govern how logs are generated and protected. |
| A.8.16 — Monitoring activities | Monitoring and review depend on logs that are useful but not overexposed. | |
| Recommendation — Apply logging controls that prevent sensitive information from being recorded. Review logs for sensitive-data leakage as part of monitoring activities. | ||
Practitioner Guidance
What to verify: Test the actual log output, not just the code review comments. Confirm that authentication headers, session identifiers, password reset artifacts, API keys, and personal data are absent from normal, error, and debug paths, including framework-generated messages and library traces.
Decision rule: If a field could let someone authenticate, impersonate a user, or reconstruct a sensitive transaction, do not log it in clear text. If engineers still need correlation, log a non-reversible reference or a tightly masked form instead.
What good looks like: Sensitive values are removed at source, log access is role-limited, and exception handling produces actionable diagnostics without exposing request contents. Redaction should be standardised in shared utilities so that new services inherit the control by default.
Common mistake: Teams often secure the application but forget the observability stack. A safe application can still leak through verbose middleware, error collectors, or support tooling that receives the same events after they leave the process.
Practitioner takeaway: The control objective is not to make logs less useful, but to ensure they remain diagnostically rich while never becoming a secondary store of secrets or other high-impact data.
Related resources from NHI Mgmt Group
- How can developers prevent sensitive information from being written to log files?
- How can organisations prevent AI-generated image descriptions from leaking sensitive information?
- How can organisations tell whether an AI system is leaking sensitive information?
- How can organisations test whether a chatbot is leaking sensitive information?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org