Cybersecurity glossary
What are Security Logging and Alerting Failures?
Learn what security logging and alerting failures are in the OWASP Top 10, why missing logs and silent alerts enable long dwell time, and how to detect and respond effectively.
Definition
Security Logging and Alerting Failures is an OWASP Top 10 category (A09:2021 Security Logging and Monitoring Failures) covering insufficient, tamperable, or unused logs and alerts—so attacks, abuse, and breaches are not detected, investigated, or responded to in time.
Why security logging and alerting failures matter
Prevention fails; detection must work. Security Logging and Alerting Failures (OWASP A09) explain why many breaches last months: the activity happened, but nobody recorded it, correlated it, or woke a human.
Without trustworthy audit trails, you also cannot investigate, contain, or prove what was accessed after an incident.
How logging failures enable attackers
Critical actions leave no useful trail
AuthZ bypasses, admin changes, or bulk exports generate no structured security events.
Logs stay local or incomplete
App instances rotate away evidence; formats lack identity, tenant, or request correlation.
No detection consumes the data
SIEM/rules are missing, noisy, or unowned—so anomalies never become alerts.
Dwell time grows
Attackers expand access while the organization remains unaware until external notice.
Failure modes under A09
Missing security events
Login failures, privilege changes, and denials are not logged at all.
Non-actionable noise
Volumes of low-value logs bury signals; alerts page nobody useful.
Tamperable storage
Attackers with host access rewrite or delete the only copy of the audit trail.
Secret-laden logs
Tokens and PII in logs create secondary disclosure and inhibit safe sharing with responders.
Logging and alerting that detect abuse
| Control | Notes |
|---|---|
| Security event catalog | Define must-log events with fields for actor, object, outcome, and correlation IDs |
| Central immutable logs | Ship to append-only or WORM-capable storage outside the app hosts |
| Detection rules | Alert on stuffing, privilege probes, admin anomalies, and integrity changes |
| Redaction | Strip secrets and unnecessary PII while retaining investigative context |
| Retention & integrity | Keep logs long enough for investigations; protect them from alteration |
| Response drills | Regularly verify alerts fire and on-call can contain the scenario |
- Document a security logging standard for authN, authZ, admin, and data-export events.
- Include user/tenant IDs, request IDs, and outcomes in structured logs.
- Forward logs to a centralized system attackers cannot easily wipe from the app host.
- Build detections for credential stuffing, BOLA probing, and privilege escalation patterns.
- Redact passwords, tokens, and secrets from application and access logs.
- Assign owners and SLAs for high-severity alerts; eliminate orphaned noise.
- Test that clock skew, sampling, and multi-region gaps do not drop critical events.
- Include logging/alerting gaps in penetration-test remediation acceptance criteria.
The practical takeaway
Security Logging and Alerting Failures (OWASP A09) leave attacks invisible. Log the security-relevant events, protect and centralize them, alert on abuse patterns, and prove with drills that someone will respond.
Related security terms
Information Disclosure
Logs themselves can leak secrets if not designed carefully.
Broken Access Control
AuthZ denials and privilege probes should generate high-value alerts.
Authentication Failures
Login anomalies are a core signal set for detection.
Web Application Firewall (WAF)
Edge signals that should feed monitoring—not replace application audit logs.
Frequently asked questions
What are security logging and alerting failures in simple terms?
Important security events are not recorded, not protected, or not watched—so attackers operate for weeks without anyone noticing.
Is A09 only about writing log lines?
No. OWASP includes monitoring and alerting. Logs without detection, retention, and response still leave you blind.
What events must be logged?
Logins, failures, MFA changes, access-control denials, admin actions, high-value transactions, input validation failures at scale, and integrity or deploy events.
Can logging create new risks?
Yes. Logging secrets, tokens, or full card data creates disclosure and compliance issues. Redact sensitive fields while keeping forensic value.
How do attackers abuse weak logging?
They prefer quiet paths: actions that leave no audit trail, log injection to confuse analysts, or deletion of local logs when write access exists.
What makes an alert useful?
A clear detection hypothesis, low noise, actionable context, an owner, and a tested response playbook—not a firehose of unprioritized SIEM noise.
How should teams improve A09 posture?
Define a security event catalog, ship immutable centralized logs, build detections for top abuse cases, and regularly test that alerts fire and pages reach humans.
References
Explore authoritative guidance and frameworks related to security logging and alerting failures.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.