Trust boundary violation occurs when a program mixes validated trusted and unvalidated untrusted data in the same variable, object, or data structure without…
Trust boundary violation occurs when a program mixes validated (trusted) and unvalidated (untrusted) data in the same variable, object, or data structure without clearly separating them. This blurs the line between what has been checked and what hasn't, making it easy for developers to accidentally use unvalidated data in a security-sensitive operation. The result is often a bypass of validation logic or use of malicious input in a dangerous context.
Trust boundary violations typically arise when developers store both user-supplied input and validated data in the same container without distinguishing between them. For example, a function might accept a user-provided string, perform some validation on it, and then store both the original input and the result in the same object or array. Later code may assume all data in that structure is safe, when in fact only part of it has been validated. This is especially dangerous when the untrusted data is later used in a security-critical operation—such as a database query, file operation, or command execution—without re-validation.
The weakness is often compounded in multi-tier applications where data flows between layers (web server to backend, frontend to API) without explicit markers indicating which fields have been sanitized and which have not.
When trust boundaries are violated, attackers can inject malicious input that bypasses validation checks. For instance, if a user ID is validated but stored alongside an unvalidated user-supplied filename in the same object, an attacker might exploit the filename field to perform path traversal or file inclusion attacks. In other cases, mixing trusted and untrusted data in a single query object can lead to SQL injection if developers assume the entire object is safe. The consequences range from unauthorized data access and modification to remote code execution, depending on how the mixed data is used downstream.
class UserRequest:
def __init__(self, user_id, filename):
self.user_id = int(user_id) # validated
self.filename = filename # untrusted, not validated
self.data = {
"id": self.user_id,
"file": self.filename
}
def process_request(req):
# Developer assumes all fields in req.data are safe
with open(f"/uploads/{req.data['file']}", "r") as f:
return f.read()Why it's vulnerable:
The filename field is never validated, but it's stored in the same data dictionary as the validated user_id. Later code treats the entire dictionary as trusted and uses the filename directly in a file path, enabling path traversal attacks.
class UserRequest:
def __init__(self, user_id, filename):
self.user_id = int(user_id) # validated
self.filename_raw = filename # keep original, marked untrusted
self.filename_safe = self._validate_filename(filename) # validated copy
def _validate_filename(self, name):
# Allowlist: only alphanumeric, dash, underscore, dot
import re
if not re.match(r'^[a-zA-Z0-9._-]+$', name):
raise ValueError("Invalid filename")
return name
def process_request(req):
# Use only the validated field
with open(f"/uploads/{req.filename_safe}", "r") as f:
return f.read()class UserRequest {
public $user_id;
public $filename;
public $data;
public function __construct($user_id, $filename) {
$this->user_id = (int)$user_id; // validated
$this->filename = $filename; // untrusted
$this->data = array(
'id' => $this->user_id,
'file' => $this->filename
);
}
}
function process_request($req) {
// Assumes all fields in $req->data are safe
$content = file_get_contents("/uploads/" . $req->data['file']);
return $content;
}Why it's vulnerable:
The untrusted filename is mixed with the validated user_id in the same data array. Downstream code treats the entire array as trusted and uses the filename in a file operation without re-validation.
class UserRequest {
public $user_id;
private $filename_raw;
private $filename_safe;
public function __construct($user_id, $filename) {
$this->user_id = (int)$user_id;
$this->filename_raw = $filename; // keep original, marked private
$this->filename_safe = $this->validate_filename($filename);
}
private function validate_filename($name) {
// Allowlist: alphanumeric, dash, underscore, dot only
if (!preg_match('/^[a-zA-Z0-9._-]+$/', $name)) {
throw new Exception("Invalid filename");
}
return $name;
}
public function get_safe_filename() {
return $this->filename_safe;
}
}
function process_request($req) {
// Use only the validated accessor
$content = file_get_contents("/uploads/" . $req->get_safe_filename());
return $content;
}filename_raw, user_input_unsafe) or access modifiers (private fields) to signal which data has not been validated.
Look for code where user input and validated data are stored together in the same array, object, or dictionary without clear separation or naming distinction. Check logs for unexpected file access patterns, unusual database queries, or errors related to path traversal or injection. If you find instances where developers are using data from a "trusted" structure without re-validating it before a sensitive operation, that is a red flag.
