Security Logging and Monitoring Failures is the risk that an attack succeeds, persists, or spreads because no one recorded it, noticed it, or responded to it in time, and it ranks number nine on the OWASP Top 10 (2021). It is the one category that is almost never the initial break-in and almost always the reason a break-in becomes a disaster. Every other Top 10 flaw is how attackers get in; A09 is why they stay in for weeks. Without reliable logs, alerting, and response, a small intrusion has all the time it needs to escalate into a full breach, and the victim frequently learns about it from a third party rather than from their own systems.
What OWASP A09 actually covers
The category describes gaps across the detect-and-respond chain. An application is vulnerable when auditable events such as logins, failed logins, and high-value transactions are not logged; when warnings and errors generate no log entries or only vague ones; when logs are not monitored for suspicious activity; when logs are stored only locally where an attacker can erase them; when there is no alerting threshold or escalation path; when penetration tests and scans do not trigger any alert; and, at the other extreme, when the application logs sensitive data such as passwords or session tokens, turning the log itself into a liability. The mapped weaknesses include CWE-778 (insufficient logging), CWE-117 (improper output neutralization for logs), and CWE-223 (omission of security-relevant information).
Why detection is ranked as a Top 10 risk
A09 rose from tenth in 2017 to ninth in 2021 and was expanded to include response, not just monitoring, reflecting how central detection has become to real-world outcomes. It is difficult to test for and rarely shows up in a single request, so it is under-represented in automated statistics, yet OWASP included it on the strength of the community survey and hard breach data. The measure that matters is dwell time, the interval between compromise and discovery. Industry reporting has repeatedly put median dwell time in the range of one to several weeks, and every day of it is time the logging and monitoring program failed to buy back.
Real-world examples
The 2017 Equifax breach is the canonical A09 lesson layered on top of another flaw. The initial entry used CVE-2017-5638, a known Apache Struts vulnerability, but the reason 147 million people's data was exfiltrated was that the intrusion went undetected for roughly seventy-six days. A network-monitoring device that would have inspected the malicious traffic had been effectively blind because of an expired certificate, so the attackers operated unseen for more than two months. The Marriott and Starwood breach disclosed in 2018 is an even starker example of dwell time: attackers had access to the reservation environment for approximately four years before anyone noticed. In both cases the exploited vulnerability was serious, but the catastrophic scale was a monitoring failure, not an exploitation one.
Vulnerable versus fixed code
The most common A09 defect in code is silently swallowing security-relevant events, especially failed authentication.
// VULNERABLE: failed logins vanish, and the catch hides errors
app.post('/login', async (req, res) => {
try {
const ok = await auth(req.body);
if (!ok) return res.status(401).send('unauthorized'); // no record
return res.send('ok');
} catch (e) {
return res.status(500).send('error'); // error swallowed
}
});
// FIXED: structured, alertable events with context and no secrets
app.post('/login', async (req, res) => {
try {
const ok = await auth(req.body);
if (!ok) {
logger.warn('auth.failure', { user: req.body.username, ip: req.ip, ts: Date.now() });
return res.status(401).send('unauthorized');
}
logger.info('auth.success', { user: req.body.username, ip: req.ip, ts: Date.now() });
return res.send('ok');
} catch (e) {
logger.error('auth.error', { ip: req.ip, err: e.message, ts: Date.now() });
return res.status(500).send('error');
}
});
The fixed version emits structured events that a central system can aggregate and alert on, records the context needed to investigate (who, where, when), and never writes the password or token itself. A burst of auth.failure events from one address is now a signal a detection rule can catch instead of an invisible brute-force attempt.
Prevention checklist
- Log all authentication events, access-control failures, and high-value transactions with enough context to investigate.
- Use a consistent, structured log format so events can be parsed, correlated, and alerted on automatically.
- Ship logs to centralized, tamper-resistant storage that a compromised host cannot quietly erase.
- Define alerting thresholds and an escalation path so suspicious patterns reach a human quickly.
- Confirm that penetration tests and vulnerability scans actually trigger alerts, closing the detection loop.
- Never log secrets such as passwords, session tokens, or full payment data; sanitize inputs written to logs.
- Retain logs long enough to support investigation of breaches that are discovered late.
- Rehearse an incident-response plan so detection reliably turns into containment.
How Safeguard helps
Detection gaps are easiest to prove by attacking your own application and watching whether anything notices, which is what Safeguard's DAST engine does when it exercises your running system and surfaces flows that should have logged an event but did not. Where insufficient logging stems from a vulnerable or misconfigured logging dependency, the SCA engine identifies the component and its advisory. Griffin AI turns raw findings into prioritized, explained guidance so your team monitors what actually matters rather than drowning in noise, which is the same triage philosophy that keeps alert fatigue from becoming its own monitoring failure. See how that approach differs from volume-first tooling on our comparison hub, and review coverage by tier on the pricing page.
Frequently Asked Questions
If logging is not an exploitable vulnerability, why is it in the Top 10?
Because the absence of detection is what turns a contained incident into a breach. Attackers rely on going unnoticed to escalate privileges, move laterally, and exfiltrate data, and every hour without an alert is an hour they operate freely. Equifax and Marriott were not breached because of poor logging, but they became historic breaches because poor logging let intruders work undisturbed for months or years.
What is dwell time and why does it matter so much?
Dwell time is the interval between the moment attackers gain access and the moment defenders detect them. It matters because impact scales with time: short dwell time can mean a blocked attempt, while long dwell time means data exfiltration and entrenched persistence. Effective logging and monitoring exist primarily to compress dwell time from weeks to minutes, which is the single biggest lever most organizations have over breach severity.
Can you log too much, and is that also an A09 problem?
Yes, on both counts. Logging sensitive data such as passwords, tokens, or full card numbers turns your logs into a high-value target and can itself trigger compliance violations, which OWASP explicitly calls out. Excessive low-value logging also buries real signals in noise and drives alert fatigue. Good logging is deliberate: capture security-relevant events with context, and never capture the secrets themselves.
How do I know whether my monitoring actually works?
Test it the way you test code. Run a controlled attack, such as a penetration test or an automated scan, and verify that the expected alerts fire and reach the right people within your target time. If a scan against your application produces no signal anywhere, that silence is the finding. Treating detection as something to be exercised and measured, not assumed, is the core discipline behind A09.
Ready to find out what your systems are missing? Start scanning at app.safeguard.sh/register, or read the setup guide at docs.safeguard.sh.