A10:2025 - Mishandling of Exceptional Conditions

Mishandling of Exceptional Conditions is new to the OWASP Top 10 in 2025, entering at position ten. This category encompasses 24 CWEs that focus on how applications behave when unexpected conditions occur, improper error handling, failing open instead of closed, ignoring return values from security functions, and logic errors that surface only under abnormal circumstances. When code does not handle exceptional conditions correctly, security controls can be silently bypassed.

Overview

Most security testing focuses on the normal execution path: valid inputs, expected responses, and successful operations. This category shifts attention to the abnormal path: what happens when a database connection fails, when memory is exhausted, when a cryptographic operation returns an error, or when two threads hit the same error handler simultaneously. Code that behaves securely under normal conditions can become completely insecure under exceptional ones.

The introduction of this category in 2025 reflects growing recognition that error handling is not just a reliability concern but a core security requirement. Many high-profile breaches have exploited error conditions: authentication systems that grant access when the user database is unreachable, authorization checks that default to "permit" when the policy engine throws an exception, and encryption routines that silently fall back to plaintext when a key is unavailable.

Radar's static analysis identifies code patterns where exceptional conditions lead to security degradation, flagging them before they can be exploited in production.

What Radar Detects

• Failing open.**Security checks that default to "allow" when errors occur, such as authentication logic that grants access when a database lookup throws an exception, or authorization middleware that passes the request through when the policy engine is unreachable.

• Empty catch blocks.**Exception handlers that catch all exceptions and continue execution silently, potentially bypassing security controls that depend on exceptions to signal unauthorized or invalid operations.

• Unchecked return values.**Return values from security-critical functions (authentication, authorization, cryptographic operations, input validation) that are ignored, meaning the calling code proceeds as if the operation succeeded regardless of the actual outcome.

• Resource exhaustion paths.**Code patterns where exceptional conditions such as out-of-memory errors, disk-full states, or connection pool exhaustion lead to security degradation, for example by disabling logging, skipping validation, or falling back to insecure defaults.

• Inconsistent error handling.**Different code paths handling the same error type differently, where some paths enforce security controls while others silently skip them, creating exploitable inconsistencies depending on which path is triggered.

• Information leakage through exceptions.**Detailed error information including stack traces, internal file paths, database connection strings, and query structures exposed in error responses sent to clients, providing attackers with valuable reconnaissance data.

• Race conditions in error handlers.**Error handling code that is not thread-safe, where concurrent error conditions can corrupt shared state, skip security logging, or create time-of-check-to-time-of-use (TOCTOU) windows that allow security bypasses.

Related CWEs

CWE-754 (Improper Check for Unusual or Exceptional Conditions), CWE-755 (Improper Handling of Exceptional Conditions), CWE-391 (Unchecked Error Condition), CWE-252 (Unchecked Return Value), CWE-396 (Declaration of Catch for Generic Exception), CWE-397 (Declaration of Throws for Generic Exception).

See the CWE Reference for details.

Prevention

• Implement explicit error handling for all security-critical operations. Authentication, authorization, cryptographic functions, and input validation must never silently fail.
• Fail closed by default: when an error occurs in a security check, deny access rather than granting it. Design every security gate so that exceptions result in denial.
• Never catch and swallow exceptions silently. Every catch block should either log the error with sufficient context, rethrow the exception to a higher-level handler, or execute a defined fallback that maintains security invariants.
• Always check return values from security-critical functions. If an authentication or authorization function returns a status code, act on it explicitly rather than assuming success.
• Use typed exceptions instead of generic catch-all handlers. Catching Exception or Throwable masks specific error conditions that require different security responses.
• Implement circuit breakers for external service dependencies so that repeated failures trigger a controlled degradation path rather than an uncontrolled cascade that bypasses security controls.
• Test error handling paths explicitly. Write tests that simulate database failures, network timeouts, resource exhaustion, and concurrent error conditions to verify that security controls remain enforced under stress.
• Configure production error responses to return generic error messages to clients while logging full diagnostic details server-side, preventing information leakage through exception details.

Next Steps