Incorrect comparison occurs when software uses the wrong operator, compares values of different types without proper conversion, or applies logic that doesn't…
Incorrect comparison occurs when software uses the wrong operator, compares values of different types without proper conversion, or applies logic that doesn't match the intended security decision. These mistakes can cause the application to make wrong authorization, validation, or authentication choices—allowing unauthorized access or bypassing security checks that should have blocked an action.
Comparison errors typically arise from three patterns: using a loose equality operator (==) instead of strict equality (===), comparing values of mismatched types without explicit casting, or using the wrong relational operator (< instead of <=, for example). In security-sensitive contexts—such as permission checks, token validation, or input bounds checking—these mistakes can flip the logic. For instance, comparing a user's role using loose equality might treat the string "0" as equal to the integer 0, or comparing a timestamp with > instead of >= might exclude the exact boundary case that should be blocked.
An incorrect comparison in an access control check could grant a user permissions they should not have. A loose comparison in authentication logic might allow an attacker to bypass a check by providing a value that coincidentally matches under type coercion. Boundary errors in validation (e.g., checking age < 18 instead of age <= 18) could allow underage users to register. These flaws are often subtle and may only manifest under specific input conditions, making them easy to miss during code review.
def check_admin_access(user_role):
# Vulnerable: loose comparison allows type coercion
if user_role == 0:
return True
return False
# An attacker could pass user_role = "0" (string) and bypass the check
# because in Python, "0" == 0 evaluates to False, but the intent was unclearWhy it's vulnerable:
The comparison doesn't enforce type consistency. If user_role is expected to be an integer but a string is passed, the logic may not behave as intended. Additionally, the condition is ambiguous—it's unclear whether 0 is meant to represent "admin" or something else.
def check_admin_access(user_role):
# Fixed: strict type check and explicit constant
ADMIN_ROLE_ID = 1
if isinstance(user_role, int) and user_role == ADMIN_ROLE_ID:
return True
return False<?php
function verify_token($provided_token, $expected_token) {
// Vulnerable: loose comparison with ==
if ($provided_token == $expected_token) {
return true;
}
return false;
}
// An attacker could pass "0e123456..." which may match "0" under loose comparison
?>Why it's vulnerable:
PHP's loose comparison (==) performs type juggling. Strings that start with "0e" followed by digits are treated as scientific notation and may unexpectedly match numeric zero or other values.
<?php
function verify_token($provided_token, $expected_token) {
// Fixed: strict comparison with === and hash_equals for timing safety
if (hash_equals($provided_token, $expected_token)) {
return true;
}
return false;
}
?>=== in PHP/JavaScript, == with explicit type checks in Python) in all security-sensitive comparisons.
hash_equals() for token/password verification) that are resistant to timing attacks.
Review your access control and authentication logs for unexpected successful checks or permission grants. Look for patterns where users with unexpected role values or types gained access. Check code comments or issue trackers for past reports of "weird edge cases" in permission or validation logic—these are often signs of comparison errors that were worked around rather than fixed.
