Redundant code — identical or near-identical logic duplicated across multiple locations in a codebase — creates a maintenance and security risk. When a…
Redundant code — identical or near-identical logic duplicated across multiple locations in a codebase — creates a maintenance and security risk. When a security bug is discovered and fixed in one copy, developers may forget to apply the same fix to other copies, leaving vulnerabilities open. This weakness is particularly dangerous because the duplication is often invisible during code review and testing.
Redundant code typically arises from copy-paste development, incomplete refactoring, or lack of code reuse discipline. A developer copies a function or validation routine to handle a similar task elsewhere, intending to refactor later but never doing so. Over time, the codebase accumulates multiple versions of the same logic. When a security issue is identified — such as insufficient input validation or an authentication bypass — the fix is applied to one location but overlooked in others. Testing may pass because the primary code path is now secure, but the duplicate paths remain vulnerable. This divergence is especially risky because the redundant code often handles edge cases or less-frequently-used features, making the vulnerability harder to detect.
An attacker who discovers a vulnerability in one code path can exploit the identical flaw in a duplicate path that was missed during patching. This can lead to authentication bypass, privilege escalation, SQL injection, or other attacks that should have been remediated. The impact is compounded because the organization may believe the vulnerability is fully fixed, reducing vigilance and delayed detection. In regulated environments, redundant unpatched code can also result in compliance violations and audit failures.
# Location 1: User login handler
def authenticate_user(username, password):
user = db.query("SELECT * FROM users WHERE username = ?", (username,))
if user and check_password(password, user['hash']):
return user
return None
# Location 2: API token validation (copy-pasted, never refactored)
def validate_api_token(username, token):
user = db.query("SELECT * FROM users WHERE username = ?", (username,))
if user and user['token'] == token:
return user
return NoneWhy it's vulnerable:
If a timing-attack vulnerability is discovered in check_password() and fixed in Location 1, the identical comparison logic in Location 2 (user['token'] == token) remains vulnerable to the same attack. The duplication means the fix must be applied twice, and if one location is missed, the vulnerability persists.
# Centralized authentication logic
def authenticate_user(username, password):
user = db.query("SELECT * FROM users WHERE username = ?", (username,))
if user and check_password(password, user['hash']):
return user
return None
# API token validation reuses the same secure comparison
def validate_api_token(username, token):
user = db.query("SELECT * FROM users WHERE username = ?", (username,))
if user and constant_time_compare(user['token'], token):
return user
return None
# Or better: extract common logic
def get_user_by_username(username):
return db.query("SELECT * FROM users WHERE username = ?", (username,))// Location 1: Admin login form
$username = $_POST['username'];
$password = $_POST['password'];
$user = $wpdb->get_row("SELECT * FROM users WHERE username = '$username'");
if ($user && wp_check_password($password, $user->password_hash)) {
$_SESSION['user_id'] = $user->id;
}
// Location 2: API endpoint (copy-pasted, never refactored)
$username = $_GET['user'];
$password = $_GET['pass'];
$user = $wpdb->get_row("SELECT * FROM users WHERE username = '$username'");
if ($user && $password === $user->api_key) {
$_SESSION['user_id'] = $user->id;
}Why it's vulnerable:
Location 1 uses parameterized queries (via wp_check_password()), but Location 2 concatenates user input directly into the SQL query. If a developer later hardens Location 1 further, Location 2 remains vulnerable to SQL injection. The duplication masks the inconsistency.
// Centralized user lookup function
function get_user_by_username($username) {
global $wpdb;
return $wpdb->get_row(
$wpdb->prepare("SELECT * FROM users WHERE username = %s", $username)
);
}
// Location 1: Admin login
$username = sanitize_text_field($_POST['username']);
$password = $_POST['password'];
$user = get_user_by_username($username);
if ($user && wp_check_password($password, $user->password_hash)) {
$_SESSION['user_id'] = $user->id;
}
// Location 2: API endpoint (reuses the same secure function)
$username = sanitize_text_field($_GET['user']);
$password = $_GET['pass'];
$user = get_user_by_username($username);
if ($user && hash_equals($user->api_key, $password)) {
$_SESSION['user_id'] = $user->id;
}Review your codebase for multiple implementations of the same function (e.g., two different password-validation routines, multiple SQL query builders, or repeated input-sanitization logic). Check your version control history for security patches applied to one file but not to similar files. If a penetration test or security audit identified a vulnerability that you believe you fixed, but the same issue resurfaces in a different code path, redundant code is likely the cause.
