When a pull request adds or changes logging, check for two opposite mistakes. Log lines that include secrets or personal data, and missing logs for events you will need during an investigation. Also check that user supplied text cannot forge or break log entries.
Data to keep out of logs
The OWASP Logging Cheat Sheet lists items to remove, mask, hash or encrypt before logging: session IDs (hash them if you need to track session events), access tokens, authentication passwords, encryption keys and other primary secrets, database connection strings, sensitive personal data such as health data and government identifiers, payment data, application source code and commercially sensitive information.
A second group needs care rather than a ban: non-sensitive personal data like names, phone numbers and email addresses, file paths, and internal network names and addresses. Consider pseudonymizing where identity is not needed.
A reviewer's table
| In the diff | Comment to leave |
|---|---|
| Logging a whole request or response object | List the fields instead. Headers may carry tokens |
| Logging an exception with its context | Check what the context object contains |
| Logging a connection string on startup | Remove or mask it |
| Logging user input in a message | Encode it for the log format |
| A debug log left in a hot path | Confirm it is off in production |
Log injection
The cheat sheet advises sanitizing event data by removing or encoding carriage returns, line feeds and delimiter characters, encoding for the log format, and treating data from other trust zones as untrusted. If a field is malformed, it suggests omitting or safely replacing it and recording the validation failure, not dropping the whole event. It cites CWE-117 for the underlying weakness.
# risky: a newline in username can forge a second entry
log.info("login failed for " + username)
# safer: structured fields are encoded by the logger
log.info("login failed", extra={"user": username})
Events worth logging
A change that removes a log line deserves as much attention as one that adds one. The cheat sheet lists events to record, among them authentication successes and failures, authorization failures, session management failures, input validation failures, application errors, configuration changes, user and privilege changes, access to sensitive data, cryptographic key use or rotation, data import and export, file uploads and deserialization failures.
Each entry should say when, where, who and what: timestamp, application and host, user or machine identity and source address, and event type with severity and description.
Practical steps
- Search the diff for logging calls and read each argument.
- For each argument, ask what the worst value it could hold is.
- Check that security relevant paths still log after the change.
- Check retention and access to the log store. A secret in a log is as exposed as the log system is.
- If a secret did reach the logs, rotate it. Deleting the line does not undo the exposure.
Where Safeguard fits
Safeguard scans dependencies and builds an SBOM, including the logging libraries you use. Try the free scan at gold.safeguard.sh/scan. What your own code logs is for your reviewers.
Quick check
Should session IDs ever be logged?
OWASP says to remove, mask, hash or encrypt them. Hash them if you need to follow a session's events.
Is user email address sensitive in logs?
It is listed as data to handle with care. Pseudonymize it where identity is not needed.
Sources
Last reviewed: 19 October 2026.
