OWASP's A09 category, Security Logging and Monitoring Failures, ranked third in its 2021 community survey. Its core point is simple: without logging and monitoring, breaches cannot be detected. Seven common beliefs about logging hold up less well than they seem, and each one maps to a concrete fix.
Myth 1: More logging is better logging
Fact. Volume is not coverage. The OWASP Logging Cheat Sheet warns about "alarm fog" from applying a checklist blindly. Log events that answer security questions, and make sure the important ones, such as logins and high value transactions, are present.
Myth 2: Logs on the server are enough
Fact. A09 lists logs kept only on the local system as a failure. A compromised host can alter local logs, and a destroyed host takes them along. Ship them elsewhere. See protecting log integrity.
Myth 3: Having logs means we are monitoring
Fact. A09 calls out application and API logs that are not monitored for suspicious activity, and missing alerting thresholds and escalation processes. Logs nobody reads detect nothing. Build a few tuned alerts and name who responds.
Myth 4: Our penetration test would have triggered something
Fact. A09 lists penetration tests and DAST scans that do not trigger alerts as a sign of weak monitoring. Treat a test as a detection exercise. Ask afterward: which of the tester's actions raised an alert, and how long did it take?
Myth 5: Logging is a developer concern only
Fact. Prevention items in A09 span engineering and operations: logging with enough user context, formatting for tools, encoding to prevent injection, integrity protection for high value audit trails, alerting, and an incident response plan such as NIST SP 800-61r2 or a later version. It needs shared ownership.
Myth 6: Logs are harmless to store
Fact. A09 includes sensitive data inserted into logs and exposure of logging details to users or attackers. It also covers unencoded log data that allows injection into logging and monitoring systems. See log injection and personal data in logs.
Myth 7: We would notice if logging broke
Fact. Silent failure is the typical case. Add heartbeat and volume alerts, as in detecting a silent log source.
A short self assessment
Answer yes or no:
- Do we log logins, failures and high value transactions?
- Are logs copied off the originating system?
- Does an alert exist for at least one attack pattern, with a named responder?
- Do we retain logs long enough for a late investigation?
- Is there integrity protection on audit trails?
- Did our last test trigger a detection?
- Do we have an incident response plan?
Each no is an action item.
Why the category is hard to measure
OWASP notes the category is hard to test and has little CVE or CVSS data, but it matters for accountability, visibility, alerting and forensics. The cost shows up after the breach, as the time between compromise and discovery.
Quick check
Is A09 only about web applications?
It is written from an application security view, but the principles apply to infrastructure, cloud and delivery pipelines too.
What is the first fix if I can do only one?
Get authentication and administrative events into a central store with a UTC timestamp and an actor ID. Everything else builds on that.
Sources
Last reviewed: 19 October 2026.
