What it means
A trust boundary marks where assumptions about identity, data, or authority change. It may lie between a browser and a server, between two organizations, or between processes running with different privileges. Crossing it requires an explicit decision about which claims and inputs can be accepted. A network perimeter is only one possible boundary.
Draw the boundary around responsibilities and trust assumptions, not merely around equipment. Input arriving from an internal system can still be wrong or attacker-controlled. Identify what the receiving component must authenticate, authorize, validate, or constrain before it acts on that input.
The idea at a glance / Access
The client supplies claims. The service checks.
A valid-looking request crosses from a supplier browser into PlantPlan. The service’s own facts determine whether it may act on it.
Fictional controlled read: session SA-17 is valid and mapped to supplier S17. S17 may read its own part records only. Target P29 belongs to supplier S29. Browser request fields are controlled by the client.
READ THE PICTURE
Read who verifies what
The browser asks to read P29 and claims supplier S17. PlantPlan validates SA-17 and looks up P29’s owner itself. The format is valid, but S17 has no read permission for S29’s record. The service refuses the read and returns no part data.
Keep in mindThis is one browser-to-application boundary and one refused read. The session and record mapping are assumptions of the fixture. A valid identifier format does not establish permission or prove that every input and downstream boundary is safe.
Read the complete example
- Read who verifies what. The browser asks to read P29 and claims supplier S17. PlantPlan validates SA-17 and looks up P29’s owner itself. The format is valid, but S17 has no read permission for S29’s record. The service refuses the read and returns no part data. The diagram summarizes one completed controlled test, not a sign-in or packet protocol. The client asks for action read, supplies target identifier P29, and sends a supplier field S17. Those browser fields can be changed, even if the device is managed or on an internal network. At the boundary, PlantPlan validates the already established session SA-17 and obtains its supplier association S17 from service-managed session state. It does not use the client’s supplier field as proof of identity or authority. The input validator accepts P29 as a syntactically valid part identifier; that checks format only. A service-controlled metadata lookup establishes that P29 belongs to supplier S29. The configured read policy requires the session supplier to match the record owner. S17 and S29 differ, and no additional cross-supplier grant exists in this fixture, so the service refuses the read before returning part content. The minimum ownership metadata needed for this decision is handled inside the service and is not returned to the browser. A permitted read of an S17 record would need the same service-side checks, not trust inherited from this request. Separate worker, database, organization, and administrative boundaries may have different privileges and assumptions; they are not drawn here. This boundary is about responsibility for accepting claims and acting on data, rather than a physical network wall.
This is one browser-to-application boundary and one refused read. The session and record mapping are assumptions of the fixture. A valid identifier format does not establish permission or prove that every input and downstream boundary is safe.
Diagram references: OWASP Threat Modeling Cheat Sheet - system modeling and trust boundaries · OWASP Authorization Cheat Sheet
AN ILLUSTRATIVE SCENARIO
A factory supplier file
A supplier uploads a parts file to a factory planning service. The supplier is trusted to provide part descriptions but is not trusted to choose database commands, operating-system paths, or another supplier's records. The upload crosses a boundary into the factory application. The receiving service checks the supplier identity and permitted scope, validates the file format, and handles the contents as data. A separate boundary limits what the file-processing worker can access if processing goes wrong.
Put it to work
- Draw the important actors, services, data stores, and flows, then mark places where ownership, privilege, or confidence in incoming data changes.
- For each crossing, state which claims must be verified and which actions the receiving component is allowed to perform.
- Test representative invalid inputs and unauthorized requests at the receiving boundary; check that failure is contained and visible to the right operator.
How to check your work
Choose one flow and trace its checks at each crossing. The diagram and implementation should agree on who verifies identity, who enforces permission, and where untrusted data becomes an action.
Connect the ideas
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
- Zero trust
An architecture approach that grants no implicit trust from network location or asset ownership and evaluates access to resources using identity, device, and other context.
- Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
- Prompt injection
An attack that inserts instructions into model input so the model follows attacker text instead of the developer’s policy.
Explore a field lesson
- Networks in one request: DNS, TCP, TLS, and HTTP
- Least privilege, defense in depth, and Zero Trust boundaries
- Application trust boundaries: why the client UI is never a security gate
- Threat modeling a service: data flows, trust boundaries, and STRIDE
- Federation failure modes: five ways SSO and token trust break