This weakness occurs when code calls a function or performs an operation but fails to check whether it succeeded or failed. When errors go undetected, the…
This weakness occurs when code calls a function or performs an operation but fails to check whether it succeeded or failed. When errors go undetected, the program may continue with invalid data, corrupted state, or incomplete results — leading to crashes, data loss, or security vulnerabilities. Proper error handling is a foundational defensive practice.
Most operations — file I/O, network calls, database queries, memory allocation, authentication checks — can fail for legitimate reasons (file not found, network timeout, permission denied, out of memory). When a developer omits the check for success or failure, the code assumes the operation worked and proceeds with whatever state resulted. This can mean using a null pointer, processing incomplete data, or trusting an operation that silently failed. Over time, unchecked errors accumulate and create conditions where the application behaves unpredictably or unsafely.
Unchecked errors can cause application crashes, data corruption, or silent failures that go unnoticed until they cause downstream harm. In security contexts, an unchecked authentication or validation error might allow an attacker to bypass a check entirely. File operations that fail silently can leave the application in an inconsistent state. Database transactions that fail without detection can result in partial updates. The impact ranges from availability issues (denial of service through crashes) to integrity issues (corrupted or incomplete data) to confidentiality issues (if error conditions expose sensitive information in logs or error messages).
import json
def load_user_config(filename):
with open(filename, 'r') as f:
config = json.load(f)
user_id = config['user_id']
return user_idWhy it's vulnerable:
The code does not check whether the file exists, whether json.load() succeeds, or whether the 'user_id' key exists in the parsed JSON. Any of these can fail silently or raise an unhandled exception, leaving the caller with no way to know the operation failed.
import json
def load_user_config(filename):
try:
with open(filename, 'r') as f:
config = json.load(f)
except (FileNotFoundError, json.JSONDecodeError) as e:
print(f"Error loading config: {e}")
return None
user_id = config.get('user_id')
if user_id is None:
print("Error: user_id not found in config")
return None
return user_id<?php
function authenticate_user($username, $password) {
$mysqli = new mysqli("localhost", "user", "pass", "db");
$stmt = $mysqli->prepare("SELECT id FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$result = $stmt->get_result();
$row = $result->fetch_assoc();
return $row['id'];
}
?>Why it's vulnerable:
The code does not check whether the database connection succeeded, whether prepare() or execute() succeeded, or whether fetch_assoc() returned a valid row. If any step fails, the code may return null or trigger a fatal error, and the caller cannot distinguish between "user not found" and "database error."
<?php
function authenticate_user($username, $password) {
$mysqli = new mysqli("localhost", "user", "pass", "db");
if ($mysqli->connect_error) {
error_log("Database connection failed: " . $mysqli->connect_error);
return false;
}
$stmt = $mysqli->prepare("SELECT id FROM users WHERE username = ? AND password = ?");
if (!$stmt) {
error_log("Prepare failed: " . $mysqli->error);
return false;
}
$stmt->bind_param("ss", $username, $password);
if (!$stmt->execute()) {
error_log("Execute failed: " . $stmt->error);
return false;
}
$result = $stmt->get_result();
$row = $result->fetch_assoc();
if ($row === null) {
return false;
}
return $row['id'];
}
?>Look for application crashes or unexpected behavior that correlates with specific conditions (file missing, network unavailable, database down). Check logs for unhandled exceptions or stack traces that suggest operations proceeded with invalid state. Review code for functions that return values without checking whether the underlying operation succeeded — this is a common sign that error conditions are being ignored.
