What Application Security Actually Controls

Application security controls aren't built to stop attackers—they're built to enforce decisions at trust boundaries. A trust boundary is any point where an application decides whether to trust something: user input, an identity claim, a service response, or data from storage. These decisions happen inside the application logic, not just at network edges.

Most application security programs organize around tool categories or vulnerability lists, but neither approach ensures complete coverage. The trust boundary model identifies where decisions must be made, what enforcement looks like, and which controls actually change outcomes.

Conceptual Model

Trust boundaries exist where applications make enforcement decisions. The application receives something—user data, an authentication token, a database response—and must decide whether to act on it. This decision point is the boundary, not the source of the input.

Six boundary types cover where applications make trust decisions. Each boundary type represents a different category of thing crossing into the application's control, requiring a different type of decision and enforcement mechanism. Understanding these six types lets you map whether your program has controls at every decision point where trust matters.

Input boundaries control what user-supplied data can become inside the application. Identity boundaries verify authentication assertions and session claims. State boundaries ensure workflow and session transitions are legitimate. Service call boundaries validate responses from internal and external services. Data access boundaries enforce per-object authorization before returning records. Runtime behavior boundaries detect when usage patterns deviate from intended application behavior.

The boundary model produces a coverage map. You can evaluate your existing controls against each boundary type and identify gaps where no enforcement exists. This reveals whether your program covers all six decision points or leaves some boundaries uncontrolled.

Six Trust Boundary Types

Boundary Type	What Crosses the Boundary	Enforcement Decision	Control Mechanism	Pattern Reference
Input	User data, API parameters, file uploads	Does the application constrain what input can become?	Parameterization, allowlists, encoding	APP-INJ cluster
Identity	Authentication assertions, session tokens, claimed roles	Does the application verify the identity before acting on it?	Authentication verification, session validation	APP-AUTH cluster
State	Workflow state, session state, application state signals	Does the application verify that state transitions are legitimate?	State integrity checks, re-validation at state changes	APP-AUTH cluster
Service calls	Responses from internal services, APIs, third-party integrations	Does the application treat service responses as trusted without verification?	Response validation, service authentication	Cross-cluster
Data access	Records retrieved from storage, queries executed	Does the application enforce per-object authorization before data is returned?	Object-level authorization, query scoping	APP-AUTH cluster
Runtime behavior	API call sequences, rate patterns, object access patterns	Does the application detect when usage deviates from intended behavior?	Behavioral baselines, anomaly detection	APP-RT cluster

Input boundaries prevent interpretation attacks when user data becomes code or commands. The application must decide whether to interpret user input directly or constrain it through parameterization and encoding.

Identity boundaries verify authentication and authorization claims before the application acts on them. The decision is whether to trust the claimed identity or require additional verification.

State boundaries ensure legitimate transitions in workflow, session, and application state. The application decides whether state changes are authorized based on current context and user permissions.

Service call boundaries validate responses from other systems before using them. The decision is whether to trust service responses directly or verify them against expected schemas and business rules.

Data access boundaries enforce authorization at the object level before returning records. The application decides whether the requesting identity should access specific data objects, not just data categories.

Runtime behavior boundaries detect anomalous usage patterns that indicate compromise or misuse. The decision is whether current behavior matches expected application usage patterns.

Mechanism Consequence

Tool-category and vulnerability-category frames fail for program design because they describe solutions and symptoms rather than decision points. Static analysis tools (SAST) find code patterns; dynamic analysis tools (DAST) test running applications; web application firewalls (WAF) filter network traffic. Each tool covers specific boundary types but none covers all six.

OWASP Top 10 categories give guidance on what type of controls to put it place. The categories are useful for describing problems but don't map to complete control coverage.

The boundary model identifies control gaps that tool and vulnerability frameworks miss. Service call boundaries often lack controls because neither SAST nor DAST typically validates service response handling. Runtime behavior boundaries require specialized monitoring that traditional application security tools don't provide.

What the boundary model produces is systematic coverage verification. You can map existing controls to boundary types and identify which decisions have enforcement and which don't. This coverage map reveals whether your program addresses all six trust decision points or leaves some boundaries unprotected.

Coverage gaps create specific risks at each boundary type. Missing input controls allow interpretation attacks like SQL injection and command injection. Missing identity controls allow unauthorized access and privilege escalation. Missing state controls allow workflow bypass and session hijacking. Missing service call controls allow response manipulation and internal service compromise. Missing data access controls allow unauthorized data retrieval and horizontal privilege escalation. Missing runtime behavior controls allow persistent compromise to continue undetected.

The tradeoff is comprehensive coverage versus focused investment. Addressing all six boundary types requires different control mechanisms and may increase implementation complexity. The alternative—focusing on specific boundary types based on risk assessment—can leave systematic gaps that create attack paths.