This weakness occurs when software fails to properly detect, catch, or respond to error conditions and exceptional events during execution. When exceptions are…
This weakness occurs when software fails to properly detect, catch, or respond to error conditions and exceptional events during execution. When exceptions are ignored, mishandled, or left unchecked, the application may continue operating in an unsafe state—potentially exposing sensitive data, corrupting state, or allowing attackers to bypass security controls. Proper exception handling is foundational to reliable and secure software.
Exceptional conditions—such as file I/O failures, network timeouts, database connection errors, or invalid input—are a normal part of software operation. When developers do not anticipate these conditions or fail to implement appropriate error-handling logic, the application may proceed with incomplete or corrupted data. Common patterns include catching exceptions but taking no action, silently swallowing errors without logging, assuming operations will always succeed, or failing to validate the result of critical operations before using them. This leaves the application in an undefined or partially-initialized state where subsequent operations may behave unpredictably or insecurely.
Unhandled exceptions can lead to information disclosure (stack traces revealing internal structure), denial of service (crashes or resource exhaustion), authentication bypass (failed security checks that are not re-attempted), data corruption (partial writes or inconsistent state), or privilege escalation (security checks skipped due to error conditions). In web applications, poor exception handling often results in verbose error messages displayed to users, leaking implementation details that attackers can exploit. In backend services, uncaught exceptions may cause silent failures that go undetected until a security incident occurs.
def process_user_data(user_id):
try:
user = database.fetch_user(user_id)
permissions = user['permissions']
data = load_sensitive_file(user_id)
except Exception:
pass
# Proceeds even if user or permissions were never set
if user['admin']:
return dataWhy it's vulnerable:
The broad except Exception: pass silently swallows all errors without logging or recovery. If database.fetch_user() fails, user is never defined, but the code continues and may crash or behave unpredictably on the next line. Security checks are bypassed.
def process_user_data(user_id):
try:
user = database.fetch_user(user_id)
if not user:
raise ValueError("User not found")
permissions = user.get('permissions', [])
data = load_sensitive_file(user_id)
except (DatabaseError, FileNotFoundError) as e:
logger.error(f"Failed to load user data: {e}")
raise # Re-raise to caller or return error response
if 'admin' in permissions:
return data
else:
raise PermissionError("User lacks admin permission")function process_payment($order_id) {
$order = @mysqli_query($db, "SELECT * FROM orders WHERE id = $order_id");
$row = mysqli_fetch_assoc($order);
charge_card($row['card_id'], $row['amount']);
update_order_status($order_id, 'paid');
}Why it's vulnerable:
The @ operator suppresses errors, so if the query fails, $row is null. The code proceeds to call charge_card() with undefined array keys, potentially charging the wrong amount or skipping the charge entirely. No logging occurs, making the failure invisible.
function process_payment($order_id) {
$order = mysqli_query($db, "SELECT * FROM orders WHERE id = ?");
if (!$order) {
error_log("Database query failed: " . mysqli_error($db));
throw new Exception("Failed to retrieve order");
}
$row = mysqli_fetch_assoc($order);
if (!$row) {
error_log("Order not found: $order_id");
throw new Exception("Order does not exist");
}
if (empty($row['card_id']) || empty($row['amount'])) {
error_log("Order missing required fields: $order_id");
throw new Exception("Invalid order data");
}
charge_card($row['card_id'], $row['amount']);
update_order_status($order_id, 'paid');
}Exception or Error classes.@ in PHP, bare except: pass in Python) without explicit logging.
Review application logs for patterns of silent failures, missing error entries, or repeated timeouts without corresponding error handling. Check for verbose error messages or stack traces visible to end users, which indicate exceptions are not being caught at the boundary. Look for incomplete transactions in your database (orders created but never charged, users registered but never activated) that suggest error handling is skipped mid-operation.
