Most applications write logs, but very few turn those logs into an alert that a person acts on before the attacker has finished. A09:2025 Security Logging and Alerting Failures is the OWASP Top 10 category for that gap: missing security events, logs that can be tampered with or that leak secrets, and monitoring that never escalates. This guide goes deeper than the overview in the OWASP Top 10 Guide: it sets out what OWASP actually requires, the ASVS 5.0 requirements that make it testable, the identity and machine credential events that are most often missed, a phased implementation plan and the evidence an assessor will ask for. It is written for application security engineers, developers who own logging libraries, and SOC and detection engineers who receive application telemetry.
Key takeaways
- The 2025 rename matters. OWASP changed the name from "Logging and Monitoring" to "Logging and Alerting" to stress that a log nobody is alerted on does not prevent or shorten a breach.
- Three CWEs carry the category. OWASP maps five CWEs, led by CWE-778 Insufficient Logging, CWE-117 Improper Output Neutralization for Logs and CWE-532 Insertion of Sensitive Information into Log File.
- ASVS V16 makes it testable. OWASP ASVS 5.0 chapter V16 Security Logging and Error Handling turns the risk into verifiable requirements, from a documented log inventory (V16.1.1) to shipping logs to a logically separate system (V16.4.3).
- Machine identities are the blind spot. Service accounts, API keys and workload tokens authenticate far more often than people, yet many applications log only human logins, so stolen machine credentials go unseen.
- Measure detection, not volume. The test of A09 is whether a simulated attack or a penetration test raised an alert and reached a responder within a defined time, not how many gigabytes were ingested.
What it is and who it applies to
OWASP describes A09:2025 as failures to log, monitor and alert on security-relevant events, which stop breaches being detected and slow incident response. It ranks ninth in the OWASP Top 10:2025 and is, in OWASP's words, underrepresented in CVE data because the weakness is rarely a single exploitable bug. Its impact is on visibility, alerting and forensics. The 2021 edition called the category Security Logging and Monitoring Failures; the 2025 edition renamed it to make alerting explicit.
The category applies to any team that builds or operates a web application or API, including internal services that only other services call. Responsibility is split: developers decide what is logged and how it is encoded, platform teams decide where logs go and who can change them, and the SOC decides which events become alerts and what the playbook says. A09 fails when any of the three assumes another has it covered.
| Data point (OWASP Top 10:2025) | A09 value | What it tells you |
|---|---|---|
| CWEs mapped | 5 | A narrow category, driven mostly by design and operations rather than code defects |
| Max / average incidence rate | 11.33% / 3.91% | Contributed test data finds it in a minority of applications, partly because automated tools struggle to test it |
| Max / average coverage | 85.96% / 46.48% | Roughly half of tested applications were checked for these CWEs at all |
| Total occurrences | 260,288 | Common in practice despite the low CVE count |
| Total CVEs | 723 | Few CVEs, because missing logging is rarely reported as a product vulnerability |
Structure and key requirements
OWASP lists the conditions that make an application vulnerable to A09. Grouped by where they occur, they form a practical requirements set.
What OWASP says goes wrong
- Missing events: auditable events such as logins, failed logins and high-value transactions are not logged, or are logged inconsistently; warnings and errors produce no log or an unclear one; unhandled errors are never logged at all (the overlap with OWASP Top 10 A10 Guide).
- Unsafe logs: logs are stored only locally, not backed up or not protected from tampering; logs expose sensitive data (CWE-532); log data is not encoded, so attackers can inject entries into logging or monitoring systems (CWE-117).
- No monitoring: application and API logs are not watched for suspicious activity; attacks cannot be detected or escalated in real time or near real time; penetration tests and DAST scans do not trigger alerts.
- Broken alerting: thresholds and escalation processes are missing or ineffective; alert use cases are missing or outdated; alerts are so noisy that real threats are missed; playbooks are incomplete or missing.
ASVS 5.0 V16 requirements that apply
| ASVS 5.0 requirement | Level | What it requires (summarised) |
|---|---|---|
| V16.1.1 | 2 | An inventory of logging at each layer of the stack: events, formats, storage location, use, access control and retention |
| V16.2.1 | 2 | Each entry carries when, where, who and what metadata for a timeline investigation |
| V16.2.2 | 2 | Synchronised time sources; timestamps in UTC or with an explicit offset |
| V16.2.4 | 2 | Logs can be read and correlated by the log processor in use, preferably in a common format |
| V16.2.5 | 2 | Logging respects data protection level: no credentials or payment data; tokens only hashed or masked |
| V16.3.1 | 2 | All authentication operations logged, successful and unsuccessful, with factor type |
| V16.3.2 | 2 | Failed authorisation attempts logged; at L3 all authorisation decisions, including sensitive data access |
| V16.3.3 | 2 | Documented security events and attempts to bypass controls such as input validation, business logic and anti-automation |
| V16.3.4 | 2 | Unexpected errors and security control failures, such as backend TLS failures |
| V16.4.1 | 2 | All logging components encode data to prevent log injection |
| V16.4.2 | 2 | Logs protected from unauthorised access and modification |
| V16.4.3 | 2 | Logs transmitted securely to a logically separate system for analysis, detection, alerting and escalation |
The OWASP Logging Cheat Sheet adds the event catalogue: input and output validation failures, authentication successes and failures, authorisation failures, session failures such as suspicious JWT validation errors, startup and shutdown of logging, administrator actions, use of default, shared or break-glass accounts, key use and rotation, data exports, deserialisation failures and backend TLS or certificate validation failures. For log platform design, retention tiers and storage cost, see the Log Management and Retention Guide; this page stays at the application layer.
Identity and NHI requirements
Identity events are the core of A09, and machine identities are where most applications fall short. An API key or service account token used from a new network, at a new rate or against a new resource is often the only signal of a stolen credential, and it is only visible if the application records which credential made the call.
| Event | Fields to record | Never record | Example alert |
|---|---|---|---|
| Human login success and failure | Account, factor type, source IP, user agent, result, reason | Password, OTP value | Many failures across accounts from one source (password spraying) |
| API key or token authentication | Key ID or token hash prefix, owning service, client ID, source, scope used | Full key or bearer token | Key used from a network or region it has never used before |
| Authorisation denial | Principal, resource, action, policy that denied | Sensitive record contents | Burst of denials by one principal across object IDs (enumeration) |
| Privilege or role change | Actor, target, old and new role, approval reference | None beyond normal PII rules | Role granted outside the change process |
| Credential lifecycle | Key or secret ID, action (create, rotate, revoke), actor | Secret value | Key created by a human on a service account |
| Break-glass or shared account use | Account, operator if known, ticket | Credential | Any use outside a declared incident |
- Attribute every machine call: log a stable, non-secret identifier for the calling NHI (key ID, client ID, workload identity) and its owner, so an analyst can answer "which integration did this" without reversing a hash. See the Service Account Security Guide.
- Keep secrets out of logs: CWE-532 is the most common way credentials leak from well-run systems: debug logging of request headers, connection strings in startup logs, tokens in URLs captured by access logs. Treat a secret found in a log as exposed and rotate it. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide.
- Honeytokens: OWASP recommends decoy data or accounts that alert when touched, which produce very few false positives. A fake API key placed in a repository or configuration file is a practical machine identity version. See the Deception Technology Guide.
- Feed identity detection: application authentication logs should reach the same pipeline as identity provider logs so that ITDR rules can correlate them. See the ITDR Guide.
The Microsoft Storm-0558 key breach shows why this matters: the US State Department detected forged-token mail access because it had premium audit logging and a custom alert on the MailItemsAccessed event, while organisations without that logging tier could not see the same activity. Microsoft later expanded default logging for all customers.
Implementation steps
- Inventory current logging: for each application, record which events are logged, at which layer, in which format, where they go, who can read or delete them and how long they are kept (ASVS V16.1.1). Mark gaps against the event table above.
- Define a security event schema: agree one structured format (JSON is the cheat sheet's preference) with when, where, who and what fields, an event type vocabulary, a severity and a security-relevant flag. Publish it as a shared library so services do not each invent their own.
- Fix encoding and redaction in the library: encode or strip CR, LF and delimiter characters, cap field lengths, and apply an allow list of loggable fields with masking for tokens and identifiers (CWE-117, CWE-532). Use parameterised log templates, not string concatenation; the cheat sheet notes that parameterisation alone does not stop CR/LF injection, so use a structured encoder.
- Instrument the missing events: start with authentication (human and machine), authorisation failures, privilege changes, credential lifecycle, input validation failures and backend TLS failures. Release behind a feature flag so the volume can be measured before full rollout.
- Ship off host and protect: forward logs over TLS to a logically separate platform the application cannot modify (ASVS V16.4.3), with append-only or immutable storage for audit trails and a dedicated, write-only account for the logging pipeline. Alert when a source stops sending (NIST SP 800-53 AU-5).
- Write alert use cases with playbooks: for each high-value event, write the detection logic, threshold, owner, escalation path and the first three response steps. Start with five to ten rules, not fifty. See the Detection Engineering Guide.
- Test end to end: run a scripted attack (credential stuffing against a test account, a burst of authorisation failures, use of a honeytoken key) and confirm each produced an alert and reached a person. Ask penetration testers to record what they did and when, then reconcile against alerts.
- Tune and roll back safely: review false positives weekly for the first month. If a new log source floods the platform, roll back by switching the feature flag or lowering verbosity for that event type, not by disabling security events wholesale.
Small versus large organisations: a small team can meet most of A09 with a managed log service, a shared logging middleware and a handful of alerts routed to an on-call channel. A large organisation needs a central schema owned by a platform team, a SIEM with correlation across identity, cloud and application sources, and detection content under version control. See the SIEM Guide.
Evidence and assessment
A09 is hard to find with scanners. OWASP's overview notes that testing relies on interviews, sampling incident responses and checking whether test attacks raised alerts. An assessor should expect the following evidence.
| Evidence | How to test | Pass indicator |
|---|---|---|
| Log inventory and schema | Document review against ASVS V16.1.1 and V16.2.1 | Every in-scope application listed with events, destination, access and retention |
| Sample log entries | Trigger a login failure, an authorisation failure and an API key call; inspect the resulting records | All fields present, UTC timestamps, no secrets or full tokens |
| Log injection resistance | Submit input containing CR/LF and delimiter characters in a test environment | Characters encoded; no forged entries appear |
| Tamper resistance | Attempt to delete or edit logs with the application's own credentials | Denied; attempt itself logged |
| Alert coverage | Map alert rules to the event inventory; run scripted attack scenarios | Each high-risk scenario raised an alert within the agreed time |
| Response | Sample recent alerts and incidents | Alert acknowledged, playbook followed, outcome recorded |
Metrics that show it is working
- Security event coverage: percentage of in-scope applications emitting all required event types in the agreed schema.
- Detection rate in tests: share of penetration test or purple team actions that produced an alert.
- Mean time to detect and to acknowledge: from first malicious event to alert, and from alert to a person taking ownership.
- Silent source count: log sources that stopped sending for more than an agreed interval.
- Secrets found in logs: secret scanner hits on log stores per month, trending to zero.
- Alert precision: share of alerts closed as true positives, tracked per rule.
Mapping to other frameworks
| Framework | Reference | Relevance to A09 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AU-2 Event Logging, AU-3 Content of Audit Records, AU-8 Time Stamps, AU-12 Audit Record Generation | What to log and what each record contains |
| NIST SP 800-53 Rev. 5 | AU-5 Response to Audit Logging Process Failures, AU-9 Protection of Audit Information, AU-11 Audit Record Retention | Silent sources, tamper resistance, retention |
| NIST SP 800-53 Rev. 5 | AU-6 Audit Record Review, Analysis, and Reporting, SI-4 System Monitoring, IR-4 Incident Handling | Turning logs into alerts and response |
| NIST CSF 2.0 | PR.PS-04, DE.CM-03, DE.AE-02, DE.AE-03 | Log generation, monitoring of activity, analysis and correlation |
| CIS Controls v8.1 | Control 8 Audit Log Management | Collect, alert, review and retain audit logs (mapped at control level) |
| ISO/IEC 27001:2022 Annex A | A.8.15 Logging, A.8.16 Monitoring activities, A.8.17 Clock synchronisation | Management system controls for the same outcomes |
| MITRE ATT&CK v20 | T1685.001 Disable or Modify Windows Event Log, T1685.005 Clear Windows Event Logs, T1070 Indicator Removal | Attacker techniques that A09 controls should detect or resist |
| OWASP ASVS 5.0 | V16.1 to V16.4 | Verifiable application requirements |
For a ready-made policy that writes these requirements down, see the Logging and Monitoring Policy Template.
Common pitfalls
- Logging success but not failure: applications that record successful logins but not failures, or human logins but not API key use, cannot see spraying, stuffing or stolen machine credentials.
- Logs on the same host as the application: an attacker with code execution can delete or edit them, and a crash or ransomware event removes the evidence. ASVS V16.4.3 exists for this reason.
- Debug logging in production: verbose logging of headers and payloads writes bearer tokens, session IDs and connection strings into a store with far wider read access than a secrets vault.
- Alerts with no owner: rules that send email to a shared mailbox, or fire so often that they are muted, are equivalent to no alert. OWASP lists noisy alerting and missing playbooks as part of the category.
- Untested detection: penetration tests and DAST scans that run without a single alert are an A09 finding in their own right, according to OWASP, yet are rarely written up as one.
- Logging tier as a licence decision: as the Microsoft Storm-0558 key breach showed, the events needed to detect an intrusion may sit in a premium tier. Check what your SaaS and cloud providers log by default.
Practitioner checklist
- Publish a log inventory per application covering events, format, destination, access and retention.
- Adopt one structured security event schema with UTC timestamps and a shared logging library.
- Log authentication for humans and machines, authorisation failures, privilege changes and credential lifecycle events.
- Record a non-secret identifier and owner for every API key, token and service account call.
- Encode log data against injection and mask or drop secrets, tokens and payment data.
- Forward logs over TLS to a separate, append-only platform and alert when a source goes silent.
- Write five to ten alert use cases with owners, thresholds and playbooks before adding more.
- Plant honeytoken API keys or accounts and confirm they alert.
- Reconcile every penetration test against the alerts it produced and track detection rate.
- Scan log stores for secrets and rotate anything found.
Standards and references
- OWASP: A09:2025 Security Logging and Alerting Failures
- OWASP: Application Security Verification Standard 5.0
- OWASP: Logging Cheat Sheet
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-92 Rev. 1 (Initial Public Draft) Cybersecurity Log Management Planning Guide
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- CISA and ASD's ACSC: Best Practices for Event Logging and Threat Detection
Related NHI Mgmt Group resources: OWASP Top 10 Guide · OWASP Top 10 A10 Guide · Secure Error Handling and Logging Guide · Log Management and Retention Guide · SIEM Guide