OWASP Security Logging and Monitoring Failures Explained

Security teams didn't discover most breaches through sensors or alerts — they discovered them months later, if at all. Why? Because OWASP insufficient logging and monitoring failures meant the attack left no discernible trail. This vulnerability wasn't originally about weak systems; it was about the absence of them: events no one could see, logs no one was watching, and no way to know if anything was wrong. The category started as A10:2017 "Insufficient Logging & Monitoring" in the OWASP Top 10 and was renamed and expanded to A09:2021 "Security Logging and Monitoring Failures" to reflect how critical observability has become. Unlike buffer overflows or injection flaws, you can't detect this failure with a port scan — it's measured in breach detection time, not vulnerability count.

This guide covers what falls under this OWASP category, what to log, what to protect, how attackers abuse logging systems themselves, and how to build logs you can actually trust and act on.

What the OWASP A09:2021 category actually covers

The category groups failures into a few core areas:

• Auditable events are not logged. Logins and failed login attempts vanish without a trace. Admin actions, privilege escalations, high-value transactions, or policy violations occur but are never recorded.
• Logs are logged but lack context. A line saying user login tells you almost nothing in production: which user, which IP, which session, which application version, which environment?
• Logs are not monitored. Millions of events flow in, but no one is watching them. Scans and penetration tests trigger no alerts. Repeated failed logins don't ring any bells. Unusual access patterns go unseen.
• Logs are stored only locally. A single-node application writes to /var/log/app.log — if the box is compromised, an attacker deletes the log. No trail remains.
• No alerting thresholds. You have logs but no rules that say "page us if X happens." Detection happens manually, if at all.
• Penetration tests don't trigger alerts. During security testing, nothing detects the probing. This is a direct test of whether your monitoring works.

The vulnerability is real. In post-breach forensics, investigators often find attackers were active for 6, 12, or 24+ months before anyone noticed. Logging was either not happening or happening in a place no one was watching.

What to log: the security-relevant events

The OWASP guidance is clear about what deserves to be an auditable event. At minimum:

• Authentication success and failure. Every login, every failed attempt, source IP, username, timestamp. Pattern: three failed logins from the same IP in 5 minutes is a credential attack.
• Authorization failures. User tried to access something they don't have permission for. User tried to modify a record they don't own. These attempts are not errors — they're security signals.
• Input validation failures. A field received data that didn't match its schema. It might be a probe for injection vulnerabilities.
• Unexpected or unhandled exceptions in production. An exception is a sign something went wrong. Unhandled exceptions are especially concerning because no one explicitly dealt with them. This is where error trackers like LightTrace come in — unhandled exceptions are auditable security-relevant events.
• Admin and privilege changes. New admin created, permission added, role changed, system configuration modified.
• Data access by privileged accounts. If an admin or system account reads sensitive data, that's worth recording.

What to NEVER log: secrets, PII, and sensitive data

This is the contrast that most posts skip — and it's the reason many logging systems become liabilities instead of assets. Here's what must never appear in a log file:

• Passwords and session tokens. Ever. Full stop.
• API keys and encryption keys.
• Full or partial credit card numbers, bank account numbers, or payment instrument details.
• Passwords in query strings. A log entry like GET /login?username=alice&password=supersecret is a treasure map for anyone with read access.
• PII in full form. Social Security numbers, full names in contexts where you don't need them, email addresses unless they're the natural identifier for the operation.
• Full request and response bodies that might contain any of the above.

The reason is this: logs are easy to ship (to a logging provider, a SIEM, a colleague's laptop), and they're easy to leak. A developer debugging an issue pastes a log line into Slack. A log aggregation service gets breached. An employee exports logs to a file. Suddenly, secrets and PII that should never have been collected are now in the wild.

Log injection and CRLF forging: attackers write fake log lines

One of the most overlooked aspects of logging security is that attackers can write to your logs directly. If you construct log messages by concatenating untrusted input, an attacker can inject fake log lines, fake audit trails, and confusion into your records.

For example:

String username = getUserInput(); // "alice\nUSER: admin LOGIN SUCCESSFUL"
logger.info("User login: " + username);

The resulting log looks like:

User login: alice
USER: admin LOGIN SUCCESSFUL

A reviewer scanning logs might be fooled into thinking an admin just logged in. This is log injection or CRLF forging (newline injection). The fix is simple: always parameterize your logs, just like parameterized queries prevent SQL injection:

logger.info("User login: {}", username); // Safe; username is data, not syntax

With parameterized logging, the newlines are escaped and appear as literal \n characters, not actual line breaks. An attacker cannot forge a new log line.

Integrity: logs must be tamper-resistant

A log file sitting on a production server is only as secure as that server. If an attacker breaks in, they can edit, delete, or truncate the log — destroying evidence. This is why serious logging setups use centralized or append-only storage:

• Centralized log aggregation. Logs are shipped immediately to a separate system — a logging provider, a SIEM, an S3 bucket — so an attacker breaking into a single app server can't erase the record.
• Append-only storage. The log destination is configured so that old entries cannot be modified or deleted, only new ones appended. Cloud platforms often offer this (e.g., S3 with MFA delete, immutable Blob Storage).
• Retention policy. Logs are kept long enough to investigate a breach (typically 90 days to a year) and deleted after, so you're not storing sensitive data forever. But during the retention window, they're immutable.

If you're using LightTrace for error tracking, the structured logs you correlate with exceptions should also follow this discipline: ship them to a centralized log aggregator (ELK, Datadog, Splunk, CloudWatch) configured for immutability, not left on a single server.

Monitoring and alerting: logs are useless if no one watches them

Collecting logs and monitoring them are not the same thing. Monitoring means alerting on patterns:

• More than N failed logins from the same IP in a time window → alert.
• User accessing data outside their normal working hours → alert.
• Privilege escalation or admin account creation → alert immediately.
• Penetration test tool signatures detected in request logs → alert.
• Repeated input validation failures from the same user or IP → alert.

These rules depend on having logs in the first place, but also on having someone (or a system) actively watching. The time to detect (TTD) a breach is one of the best measures of whether your logging and monitoring actually work. OWASP notes that organizations without effective monitoring often discover breaches weeks or months after they begin — the same investigation finds logs were being collected all along, just never examined.

Where LightTrace fits

LightTrace captures unhandled exceptions from your application and stores them with full context: stack trace, breadcrumbs, affected user, release version, environment, and tags. An unhandled exception in production is a security-relevant event — it means code you didn't expect to run just ran, or an assumption you made was violated. LightTrace's sensitive-data scrubbing ensures that passwords, tokens, and PII are redacted from the exception data before storage.

LightTrace is not a log management system or a SIEM — it does not ingest syslog, parse arbitrary text logs, or provide a rules engine for monitoring. But it does handle one of the most important audit trails: application errors. Paired with a centralized structured-logging system and alert rules for authentication and authorization events, LightTrace completes the picture of what's happening in your production environment. The same trace_id or request_id that threads through your logs can be captured in an exception's context, so you can pivot from a grouped error issue directly to the correlated log entries and reconstruct the full incident.

Putting it together

OWASP A09:2021 Security Logging and Monitoring Failures is not a single bug you can patch — it's a discipline. It requires:

1. Logging the right events: Logins, failed attempts, authorization decisions, input validation failures, admin changes, unhandled exceptions.
2. Logging safely: No secrets, no PII, parameterized messages to prevent injection.
3. Protecting logs: Centralized or append-only storage, immediate transmission out of the source server.
4. Monitoring: Alert rules that trigger on the patterns that matter. Not every event, but the ones that indicate an attacker or a misconfiguration.
5. Testing: Penetration testers should see alerts fire. If a scan doesn't trigger anything, your monitoring isn't working.

The cost of not doing this is measured in time: the longer a breach goes undetected, the more damage occurs. Organizations with mature logging and monitoring detect breaches in days instead of months. That difference is worth the effort.