A09:2025 - Security Logging and Alerting Failures

Security Logging and Alerting Failures holds position nine in the OWASP Top 10 for 2025, renamed from "Security Logging and Monitoring Failures" in the 2021 edition. This category moved up from the tenth position in the 2017 list. While logging weaknesses are inherently difficult to detect through static analysis alone, specific code patterns reliably indicate that an application will fail to produce adequate security logs or will inadvertently expose sensitive data through its logging.

Overview

Without sufficient logging and alerting, breaches go undetected and incident response becomes impossible. The average time to identify a breach exceeds 200 days in organizations with inadequate logging practices. This category covers two sides of the same problem: not logging enough security-relevant events (making attacks invisible) and logging too much sensitive information (creating a new attack surface in log storage).

The 2025 rename from "Monitoring" to "Alerting" emphasizes that passive log collection without active alerting provides minimal security value. Simply writing logs to a file is insufficient. Those logs must feed into alerting systems that notify security teams of suspicious activity in near real time.

Radar identifies code patterns on both sides of this problem: places where logging is missing or insufficient around security-critical operations, and places where sensitive data such as credentials and PII is being written into log output.

What Radar Detects

• Sensitive data in log statements.**Code that writes passwords, authentication tokens, credit card numbers, Social Security numbers, or other personally identifiable information (PII) directly into log output, creating a secondary exposure vector if logs are accessed by unauthorized parties or stored insecurely.

• Missing error handling on security-critical operations.**Database queries, authentication checks, file system operations, and network calls that execute without try/catch blocks or equivalent error handling, meaning failures in these operations are neither logged nor handled gracefully.

• Swallowed exceptions.**Catch blocks that silently discard exceptions without logging the error or rethrowing it, effectively hiding failures that may indicate security-relevant conditions such as failed authorization checks, corrupted data, or denial-of-service conditions.

• Logging credentials in request data.**Log statements that output entire HTTP request bodies, full header collections, or complete request objects, inadvertently capturing authentication tokens, session cookies, API keys, and other credentials embedded in the request.

• Missing audit trails for administrative actions.**Administrative operations such as user creation, role changes, permission grants, and configuration modifications that execute without generating an audit log entry, making it impossible to reconstruct who did what during an investigation.

• Log injection vulnerabilities.**User-controlled input written directly into log entries without sanitization, allowing attackers to inject fake log entries, corrupt log integrity, or exploit log parsing tools through crafted input containing newlines or log format control characters.

Related CWEs

CWE-778 (Insufficient Logging), CWE-223 (Omission of Security-Relevant Information from Audit Log).

See the CWE Reference for details.

Prevention

• Log all authentication events, both successful and failed login attempts, along with all authorization failures, including the user identity, timestamp, source IP, and the resource or action that was denied.
• Use structured log formats (JSON, key-value pairs) that are compatible with centralized log management and SIEM tools, enabling automated parsing, correlation, and alerting.
• Never log credentials, tokens, session identifiers, or PII. Implement a sanitization layer that strips or masks sensitive fields before they reach the log output.
• Implement alerting rules for suspicious patterns such as repeated authentication failures from a single IP, privilege escalation attempts, or access to administrative endpoints by non-admin users.
• Ensure all catch blocks either log the exception with sufficient context for investigation or rethrow it to a higher-level handler. Never silently discard exceptions.
• Sanitize all user-controlled input before including it in log entries to prevent log injection and log forging attacks.
• Generate audit log entries for all administrative and privileged operations, stored in a tamper-evident log store separate from application logs.
• Establish and regularly test an incident response plan that defines how security alerts are escalated, investigated, and resolved within defined time windows.

Next Steps