Log security-relevant events: authentication results, access control failures, validation failures, errors and high-risk actions. Keep secrets such as passwords, access tokens and session identifiers out of the logs entirely. Then protect the logs from tampering and from injected content, because attackers read and forge them.
Events worth logging
The OWASP Logging Cheat Sheet lists what to log where possible:
- Input and output validation failures.
- Authentication successes and failures.
- Authorization (access control) failures.
- Session management failures, such as suspicious token validation failures.
- Application errors and system events: connectivity problems, third-party errors, file system errors, malware detected in uploads and configuration changes.
- Startup, shutdown and logging initialization.
- Higher-risk functionality: user and privilege changes, administrator actions, use of shared or break-glass accounts, sensitive data access, key use or rotation, data import and export, file uploads and deserialization failures.
- Consent and opt-in events.
- Suspicious business logic activity, such as out-of-order steps or attempts to exceed limits.
The guide adds a caution on severity: validation failures against a fixed list of allowed values may reflect misuse or a client bug rather than an attack, so judge by repetition, correlation and context.
What never to log
The cheat sheet says these must be removed, masked, sanitized, hashed or encrypted before recording:
- Application source code
- Session identifiers (a hashed value may be used for tracking)
- Access tokens
- Authentication passwords
- Database connection strings
- Encryption keys and other primary secrets
- Bank account or payment card data
- Sensitive personal data and some PII
- Commercially sensitive information
- Data a user opted out of, or never consented to, having collected
Its blunt rule: never log data unless it is legally sanctioned. The reason is that logs often have a wider audience than the production database: support staff, a third-party log platform, an attached bug report.
Protect the logs
- Tamper detection. Build in a way to notice if a record was modified or deleted. Move log data to read-only media as soon as practical.
- Access control. Record and monitor access to logs, restrict read privileges and review them.
- Transport. Use a secure protocol, for example syslog over TLS, when logs cross untrusted networks.
- Gaps. Detect when logging stops. Silence is a signal.
Prevent log injection
Attacker-controlled text can forge log lines or attack the platform that reads the logs. The cheat sheet recommends sanitizing event data, including carriage returns, line feeds and delimiters, encoding data for the output format, and treating data from other trust zones as untrusted. Also make sure logging failures neither stop the application nor leak information, and that logging cannot be abused to exhaust disk space.
A starter checklist
- Pick the ten events above that matter most for your app and log them with a user ID, time, source and outcome.
- Search a day of logs for tokens, passwords, emails and card numbers. Fix each source.
- Add a field filter in your logging library that redacts known sensitive keys.
- Send logs off the host, with restricted access.
- Alert on a stop in log volume.
- Test with a request containing newline characters and confirm the log stays well formed.
For how errors fit with logging, see error handling that does not leak.
Quick check
Can I log session IDs for debugging?
Not in raw form. The cheat sheet says a hashed value may be used if you need to correlate activity.
Should I log every validation failure?
Yes where possible, but judge severity by pattern. One failure is often a user typo.
Sources
Last reviewed: 19 October 2026.
