What Application Security Actually Controls

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 | 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.Sources https://owasp.org/Top10/https://csrc.nist.gov/publications/detail/sp/800-95/final