Trust Boundary

A line in a system where the level of trust changes, so anything crossing it must be validated, authenticated, or authorized rather than assumed safe. Inside a boundary, components trust each other; data and requests arriving from outside are treated as potentially hostile until checked. Identifying trust boundaries is the backbone of reasoning about where attacks can enter.

Why it Matters

Most security failures happen because something crossed a boundary unchecked: input that was trusted, a caller assumed to be authorized, data from another system taken at face value. Naming trust boundaries tells you exactly where validation and authorization must live, and turns "is this safe?" into a concrete question asked at specific lines rather than everywhere or nowhere.

Signals

• The team can point to where untrusted input enters and where privilege changes.
• Validation and authorization happen at those lines, not scattered or missing.
• Data from external systems is checked at the boundary, not trusted because "it's internal."

Benefits

A precise map of where defenses belong, validation concentrated at the lines that matter, and a shared vocabulary for discussing exposure.

Risks

Assuming an internal boundary is safe (a soft interior behind a hard shell); validating in some paths but not others; drawing boundaries that do not match where trust actually changes, so the checks guard the wrong places.

Tensions

Every boundary check costs performance and code, and over-validating internally adds friction; under-validating trusts too much. The judgment is where trust genuinely changes, the security analogue of choosing any other boundary in the system.

Examples

Treating all input at a public API as untrusted and validating it there, while a request arriving from another service across the network is still checked rather than trusted by origin.