This weakness occurs when code calls an API, library function, or protocol without adhering to its documented requirements or constraints. The caller may omit…
This weakness occurs when code calls an API, library function, or protocol without adhering to its documented requirements or constraints. The caller may omit required parameters, pass invalid values, ignore return codes, or misuse the component in ways the specification explicitly forbids. This mismatch between expected and actual usage can cause the invoked component to fail silently, behave unpredictably, or enter an insecure state.
APIs and libraries are designed with specific contracts: required parameters, valid input ranges, expected error handling, and proper sequencing of calls. When a caller ignores these contracts—either through misunderstanding, carelessness, or deliberate shortcuts—the invoked component may not behave as intended. For example, a cryptographic function might require a minimum key length; if the caller provides a shorter key, the function may still execute but produce weak encryption. Similarly, a file operation might require explicit permission checks before opening; if the caller skips this step, access control is bypassed. The specification exists to ensure security properties hold; violating it breaks those guarantees.
Improper API usage can lead to authentication bypass, weak cryptography, privilege escalation, or data exposure. For instance, ignoring a library's requirement to validate input before processing can allow malicious data to propagate. Failing to check error codes from security-critical functions (like permission checks or certificate validation) can silently allow insecure operations to proceed. In protocol implementations, skipping required handshake steps or validation phases can undermine the entire security model.
import hashlib
# Caller ignores the library's documented requirement
# to use a salt with password hashing
user_password = "user_input"
password_hash = hashlib.md5(user_password.encode()).hexdigest()
# Store password_hash in databaseWhy it's vulnerable:
The specification for secure password storage requires a salt and a slow hash function (like bcrypt or PBKDF2). Using MD5 without salt violates this requirement and produces weak hashes vulnerable to rainbow tables.
import bcrypt
user_password = "user_input"
salt = bcrypt.gensalt()
password_hash = bcrypt.hashpw(user_password.encode(), salt)
# Store password_hash in database<?php
// Caller ignores the requirement to validate the certificate
// when making an HTTPS request
$context = stream_context_create([
'ssl' => [
'verify_peer' => false, // Specification says this should be true
'verify_peer_name' => false
]
]);
$response = file_get_contents('https://api.example.com/data', false, $context);
?>Why it's vulnerable:
The SSL/TLS specification requires peer certificate verification to prevent man-in-the-middle attacks. Disabling verification violates this requirement and exposes the connection to interception.
<?php
// Follow the specification: verify the peer certificate
$context = stream_context_create([
'ssl' => [
'verify_peer' => true,
'verify_peer_name' => true,
'cafile' => '/path/to/ca-bundle.crt'
]
]);
$response = file_get_contents('https://api.example.com/data', false, $context);
?>Look for code that calls cryptographic, authentication, or file-access functions without checking return values or error codes. Search for disabled security checks (e.g., verify_peer = false, SSL_VERIFYPEER = 0) or use of weak algorithms where the specification recommends stronger ones. Review logs for unexpected failures or silent errors in security-critical operations that might indicate the invoked component is not behaving as expected.
