This weakness occurs when software has access to a security control—such as input validation, authentication, encryption, or access checks—but either doesn't…
This weakness occurs when software has access to a security control—such as input validation, authentication, encryption, or access checks—but either doesn't use it or uses it incorrectly. The protection exists in the codebase but is bypassed, misconfigured, or applied inconsistently, leaving the application vulnerable to attacks it should be able to defend against.
Protection mechanism failures typically arise in one of three ways. First, a developer may be aware of a security function but choose not to call it, either due to misunderstanding its necessity or underestimating the risk. Second, the protection may be implemented but applied only to some code paths while others are left unguarded—for example, validating user input in one form handler but not another. Third, the mechanism may be used incorrectly: a password hashing function called with weak parameters, an encryption library initialized without proper key derivation, or an access control check that evaluates the wrong condition. In all cases, the defensive capability exists within reach but fails to protect the application.
When protection mechanisms are not properly deployed, attackers can exploit the same vulnerabilities the mechanisms were designed to prevent. An application with input validation functions that are selectively applied may still suffer SQL injection or cross-site scripting attacks on unprotected endpoints. Weak or missing authentication checks can lead to unauthorized access. Inconsistent encryption or missing HTTPS enforcement can expose sensitive data in transit. The severity depends on which protection is bypassed—a failure to validate file uploads might allow arbitrary code execution, while a missing rate-limit check could enable brute-force attacks on login forms.
import sqlite3
def get_user_by_id(user_id):
# Validation function exists but is not called
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
# Direct string concatenation without validation
query = f"SELECT * FROM users WHERE id = {user_id}"
cursor.execute(query)
return cursor.fetchone()
def validate_input(value):
# Protection mechanism exists but is unused
if not isinstance(value, int) or value < 0:
raise ValueError("Invalid input")
return valueWhy it's vulnerable:
The validate_input() function exists but is never called before constructing the SQL query. An attacker can pass a malicious string as user_id to manipulate the query.
import sqlite3
def get_user_by_id(user_id):
# Validation is called before use
validated_id = validate_input(user_id)
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
# Parameterized query prevents injection
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (validated_id,))
return cursor.fetchone()
def validate_input(value):
if not isinstance(value, int) or value < 0:
raise ValueError("Invalid input")
return value<?php
// Authentication check function exists
function is_admin() {
return isset($_SESSION['role']) && $_SESSION['role'] === 'admin';
}
// But is not called in all sensitive operations
function delete_user($user_id) {
// Missing is_admin() check here
global $wpdb;
$wpdb->query($wpdb->prepare("DELETE FROM users WHERE id = %d", $user_id));
return true;
}
function edit_settings($settings) {
// Protection is called here
if (!is_admin()) {
die('Unauthorized');
}
update_option('site_settings', $settings);
}Why it's vulnerable:
The is_admin() check is implemented and used in edit_settings() but is missing from delete_user(), creating an inconsistent security posture.
<?php
function is_admin() {
return isset($_SESSION['role']) && $_SESSION['role'] === 'admin';
}
function delete_user($user_id) {
// Protection is now consistently applied
if (!is_admin()) {
die('Unauthorized');
}
global $wpdb;
$wpdb->query($wpdb->prepare("DELETE FROM users WHERE id = %d", $user_id));
return true;
}
function edit_settings($settings) {
if (!is_admin()) {
die('Unauthorized');
}
update_option('site_settings', $settings);
}Look for inconsistent security controls across similar functions—for example, some API endpoints that validate input and others that don't, or admin functions that check permissions in some places but not others. Review logs for unexpected data modifications, unauthorized access attempts that succeeded, or SQL errors that suggest injection attempts. Check whether security functions exist in your codebase but have zero or very few call sites; unused protection mechanisms are a red flag.
