This weakness occurs when software accepts input that should be a specific data type integer, email, URL, etc. but fails to properly verify that the input…
This weakness occurs when software accepts input that should be a specific data type (integer, email, URL, etc.) but fails to properly verify that the input actually matches that type before using it. An attacker can supply data of the wrong type to trigger unexpected behavior, bypass security checks, or cause the application to crash or behave unpredictably.
Applications often assume that input will arrive in the expected format without explicitly checking. For example, a function might expect an integer ID parameter but receive a string, or expect a numeric value but receive an object. When the code proceeds to use this mistyped input in operations designed for the original type—arithmetic, array indexing, method calls, or database queries—the results can be unpredictable. Type coercion in some languages may silently convert values in unexpected ways, masking the problem until it causes harm downstream.
Improper type validation can lead to logic errors, information disclosure, or denial of service. An attacker might supply a string where an integer is expected, causing a calculation to fail or return incorrect results. In some cases, type confusion can bypass authentication checks or allow an attacker to access unintended code paths. The impact ranges from minor functional bugs to security-relevant flaws depending on how the mistyped input is used.
def process_user_id(user_id):
# Assumes user_id is an integer, but doesn't validate
query = f"SELECT * FROM users WHERE id = {user_id}"
result = database.execute(query)
return result[0]
# Attacker supplies a string instead
user_data = process_user_id("1 OR 1=1")Why it's vulnerable:
The function assumes user_id is an integer and directly interpolates it into a query string without type checking. An attacker can pass a string containing SQL syntax, leading to injection.
def process_user_id(user_id):
# Validate that user_id is actually an integer
if not isinstance(user_id, int) or user_id < 0:
raise ValueError("user_id must be a non-negative integer")
# Use parameterized query
query = "SELECT * FROM users WHERE id = ?"
result = database.execute(query, (user_id,))
return result[0] if result else None<?php
function get_post($post_id) {
// Assumes $post_id is numeric, but doesn't validate type
$query = "SELECT * FROM posts WHERE id = " . $post_id;
$result = mysqli_query($connection, $query);
return mysqli_fetch_assoc($result);
}
// Attacker supplies a string
$post = get_post($_GET['id']);
?>Why it's vulnerable:
The function concatenates $_GET['id'] directly into the query without checking its type or using prepared statements. An attacker can inject SQL by passing a malicious string.
<?php
function get_post($post_id) {
// Validate that $post_id is a positive integer
if (!is_numeric($post_id) || intval($post_id) <= 0) {
throw new InvalidArgumentException("post_id must be a positive integer");
}
// Use prepared statement
$stmt = $connection->prepare("SELECT * FROM posts WHERE id = ?");
$stmt->bind_param("i", intval($post_id));
$stmt->execute();
return $stmt->get_result()->fetch_assoc();
}
?>isinstance() in Python, is_int() / is_numeric() in PHP, or language-native type checks before processing.
declare(strict_types=1)) where possible.
Look for unexpected errors in application logs mentioning type mismatches, failed arithmetic operations, or "undefined method" errors when processing user input. Check for cases where user-supplied values are used in calculations or database queries without prior validation, or where the application behaves differently when given unusual input types (e.g., a string instead of a number).
