Never write passwords, access tokens, session identifiers, encryption keys, database connection strings, payment data or sensitive personal data to logs in raw form. OWASP says these should be removed, masked, sanitized, hashed or encrypted before logging. Logs are copied widely, so a secret in one becomes a secret everywhere.
The list
The OWASP Logging Cheat Sheet names items that usually should not be recorded directly:
- Application source code
- Session identification values, with hashing as an option when you need to track session events
- Access tokens
- Sensitive personal data and some personally identifiable information, such as health or government identifiers
- Authentication passwords
- Database connection strings
- Encryption keys and other primary secrets
- Bank account or payment card holder data
- Data of a higher classification than the logging system is allowed to store
- Commercially sensitive information
- Information it is illegal to collect in the relevant jurisdictions, or that a user has opted out of
It adds a second group that may need special handling before recording: file paths, internal network names and addresses, and some non sensitive personal data.
Why logs are a good place for secrets to hide
Logs are read by many people and tools: developers, on call staff, a log platform, a vendor. They are retained for long periods and copied to backups. If a secret lands there, rotation is the only reliable fix. See what to do first when a live secret appears in logs.
Typical causes are mundane:
- Logging a whole request or response object, headers included.
- Logging an exception that contains a connection string.
- Debug logging left on in production.
- Query strings that carry tokens; see Nginx access logs and query strings.
- Telemetry attributes copied from request data.
Controls that work
| Control | How it helps |
|---|---|
| Allowlist fields | Log only named fields, not whole objects |
| Redaction in the logger | Mask known keys such as authorization, password and token before output |
| Redaction in the pipeline | A second layer in the collector, see OpenTelemetry redaction |
| Debug off by default | Require a deliberate, time boxed change to raise levels |
| Tests | Unit tests that fail if a sample secret appears in output |
| Access control | Limit who can read raw logs and for how long |
Hash instead of drop when you need correlation
If you need to follow one session or user across events, log a keyed hash or an internal ID, not the raw value. OWASP explicitly allows hashing a session value for this purpose. An internal user ID is generally safer than an email address.
What to do if you already logged something
Treat it as exposure. Rotate the credential, find where the logs went including exports and vendors, and fix the code path. Deleting the line from the primary store is not enough if copies exist. Then add the test that would have caught it.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the code scan and look at how a finding points to the exact line, which is how you track down risky logging calls.
Quick check
Is it okay to log the last four digits of a card number?
Rules differ by standard and context, so check your payment and privacy requirements first. Safer defaults are to avoid card data in logs altogether.
Should I log request headers for debugging?
Not by default. The authorization and cookie headers carry credentials. If you must, redact those headers before writing.
How do I find secrets already in my logs?
Search your log store for patterns such as bearer prefixes and key formats, then rotate anything live and fix the code that wrote it.
Where Safeguard fits
Safeguard's SAST and dependency scanning help review the code and libraries that handle logging, and compliance and evidence automation helps you retain proof of your logging controls. Try the free scan.
Sources
Last reviewed: 19 October 2026.
