COMMON WEAKNESS ENUMERATIONDraft

CWE-501

Trust Boundary Violation

The product mixes trusted and untrusted data in the same data structure or structured message.

Abstraction

Base

Structure

Simple

Likelihood of Exploit

Medium

Understand the problem

What is the problem?

The product mixes trusted and untrusted data in the same data structure or structured message.

Extended description

A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data.

Root cause

How and when does the problem arise?

Lifecycle phase

Architecture and Design

Risk

What does successful exploitation lead to?

Bypass Protection Mechanism

Affected security scopes: Access Control

Defence

How is it prevented and fixed?

  • Follow secure coding guidelines for input handling and boundary checking.
  • Enforce strict security reviews and automated static analysis (SAST) checks.

Verification

How is it detected?

Automated Static Analysis

High
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)