A09/Security Logging & Alerting Failures — OWASP Top 1000 / 11
A09
OWASP Top 10 · 2025
Security Logging &
Alerting Failures
The breach lasted 78 days. Nobody noticed. The logs existed — nobody read them. The alerts? There were no alerts.
// the blind spot — three breaches, one pattern

In 2017, Equifax was breached for 78 days before discovery. 147 million records. A children's health plan provider in the US was breached for over seven years — an external party informed them. Air India lost 10 years of passenger data, including passport and credit card numbers, through a third-party cloud provider that didn't notify them promptly. In every case, the technical vulnerability was real — but the catastrophic scale came from the same failure: nobody was watching. The logs were incomplete. The alerts didn't exist. The breach was discovered by outsiders, not by the organization.

In 2025, OWASP renamed this category from "Monitoring" to "Alerting" — because great logs with no alerts provide minimal value. IBM's data shows organizations that detect breaches within 200 days save an average of $1.02 million compared to those that take longer. The question isn't whether you log. It's whether anyone wakes up at 2am when something bad is happening.

// classify the failure

An application logs 10GB of data per day. It has a log aggregation platform. A breach runs undetected for 6 months. What's the most likely problem?

💾 Not enough log storage
Logs were rotated too aggressively and critical evidence was deleted before analysis.
🔔 No alerting on security events
Logs existed but no rules turned patterns (failed logins, privilege escalation) into actionable alerts.
🔐 Logs were encrypted
The encryption made it too difficult for the security team to search and analyze log data.
📊 Wrong log format
Unstructured text logs couldn't be parsed by the aggregation platform for pattern analysis.
// find the logging failure

A Node.js authentication logger. It logs something on every request. Two things are wrong: it logs what it shouldn't, and it doesn't log what it should. Click the worst line.

middleware/audit.js
// what attackers see vs what you see
step 1 of 3

Log the right things. Alert on what matters.

wrong
right

The fix isn't more logging. It's structured logging of security-relevant events, with alerting rules that turn patterns into pages.

🎯 the one habit

Log auth failures, privilege changes, bulk data access. Never log passwords, tokens, or PII. If no alert would fire at 2am during a breach, your logging is decoration.

What to log
Alerting rules
What NOT to log
audit.js
click the dot
why this works
// knowledge check
1 / 3

Your application logs failed login attempts. 500 failures from different IPs against the same account occur in 10 minutes. What should happen?

A — Log the events and include them in the weekly security report for the team to review
B — Trigger an immediate alert to the on-call engineer and temporarily lock the targeted account
C — Block all the source IPs at the firewall level to prevent further attempts from those addresses
// knowledge check
2 / 3

A developer adds logger.info("Login: " + email + " password: " + password) to help debug authentication issues. What's wrong?

A — Passwords in logs are a data breach waiting to happen — anyone with log access sees credentials
B — The string concatenation is inefficient and should use template literals for better performance
C — The log level should be debug instead of info so it only appears in development environments
// knowledge check
3 / 3

In 2025, OWASP renamed this category from "Monitoring" to "Alerting." Why?

A — Monitoring tools have become too expensive for most organizations to maintain effectively
B — The industry shifted from active monitoring to AI-powered passive analysis of historical data
C — Logs without alerts are passive evidence. Alerting emphasizes that detection must be active and real-time
// self-check complete

// the mental model

carry this into your next incident review

A log that nobody reads is a liability, not a defence. An alert that nobody responds to is noise, not security. The goal isn't more data — it's the right data, with the right trigger, reaching the right person.

A09 · Security Logging & Alerting Failures
Scope in 2025
Missing logs · PII in logs · no alerts · log injection · insufficient retention
▶
A09 holds #9 in 2025 with a name change: "Monitoring" → "Alerting." 5 CWEs, 260K occurrences. CWE-778 (insufficient logging), CWE-117 (log injection), CWE-223 (omitted security info), CWE-532 (sensitive info in logs). OWASP emphasizes: great logging with no alerting provides minimal value. Ownership is shared: app developers must emit the security events (auth failures, privilege changes, bulk data access); the platform/SOC team builds the alerting and detection on top. A SIEM is blind without the events the application instruments.
First fix
Add one alert: >10 failed logins per account per hour → page the on-call
▶
Start with the highest-signal alert: concentrated failed authentication against a single account. This catches credential stuffing, brute force, and account takeover attempts. Use your log aggregation platform (ELK, Datadog, CloudWatch) to create a threshold rule. Then add: privilege escalation events, new admin account creation, access control failures, and anomalous data export volumes. Each alert should have a defined owner and response playbook.
The $1.02M gap
IBM: breaches detected within 200 days save $1.02M vs those detected later
▶
IBM's Cost of a Data Breach Report found a $1.02 million difference between breaches detected and contained within 200 days vs those that took longer. Equifax: 78 days undetected, 147M records, $700M+ total cost. The children's health plan: 7+ years undetected, 3.5M children's records modified. Every day an attacker operates undetected, the blast radius grows. Detection speed is the single most impactful factor in breach cost.
Signal vs noise
Five high-signal alerts · what NOT to alert on · avoiding alert fatigue
▶
Start with five high-signal alerts: (1) >10 failed logins per account/hour, (2) new admin account created, (3) privilege escalation event, (4) bulk data export above baseline, (5) access control failure spike. Don’t alert on: individual 404s, single failed logins, routine scanning noise, or any event that fires more than 50 times/day without action — that’s not an alert, it’s a log line. The test: if the on-call ignores this alert three times running, delete it — ignored alerts train people to ignore alerts. Every alert must have a defined owner and a one-page response playbook, or it’s noise pretending to be security.

// check your logging and alerting today

Five things you can verify right now.

Authentication events are logged
Successful logins, failed logins, MFA events, password resets — all logged with user ID and IP?
At least one security alert exists
Do you have any alert that would fire on brute force, privilege escalation, or mass data access?
No sensitive data in logs
Search your logs for passwords, tokens, SSNs, credit cards. They should not be there.
Log retention meets compliance
How long are logs retained? 30 days? 90? A 7-year breach needs 7 years of evidence.
Someone is on call
If an alert fires at 2am, who gets paged? Is there a defined response playbook?
0 / 5