A trust boundary is the line on a Data Flow Diagram where data crosses from one zone of trust into another — and it's disproportionately where real vulnerabilities live. Most serious security bugs aren't exotic cryptographic flaws; they're a place where code on one side of a boundary trusted data from the other side more than it should have.
Quick definition: A trust boundary marks any point where data moves between two parts of a system that don't trust each other equally — e.g. the public internet and your API, or an unauthenticated request and an authenticated session.
Common trust boundaries
- Client ↔ server — anything a browser or mobile app sends is attacker-controlled until your server validates it, no matter what client-side validation exists.
- Public internet ↔ internal network — the classic perimeter, though modern architectures increasingly need internal boundaries too (see below).
- Unauthenticated ↔ authenticated — the moment a request goes from "anyone" to "this specific logged-in user," every downstream assumption about who's asking changes.
- Your service ↔ a third-party API or webhook — data you didn't generate and can't fully control the shape or timing of.
- User-role boundaries — a standard user's session and an admin's session are different trust zones even though both are "authenticated."
Note that trust boundaries aren't only about the network perimeter. A monolith calling into its own database still crosses a meaningful boundary if that database also accepts writes from a background job with different validation than the API does — trust boundaries are about differing assumptions, not physical distance.
Why boundaries matter more than any single element
When you apply STRIDE to a Data Flow Diagram, the elements sitting directly on a trust boundary deserve the most scrutiny, because that's exactly where a design can quietly assume the wrong thing was already checked. A process that reads from a data store on the same side of a boundary can often reasonably trust that data; the same process reading a value that just crossed a boundary cannot, and every field it consumes from that flow needs an explicit answer to "what if this is malicious?"
A concrete example: an internal admin API that only checks authentication (is this someone logged in?) but not authorization (is this someone logged in with admin rights?) has, in effect, no trust boundary between regular users and admins at all — even though the diagram might show one. The boundary you draw on paper only means something if the code actually enforces it.
How to find them on your own system
The fastest way to find trust boundaries is to trace every place data enters your system from outside your own code — form submissions, API requests, webhook payloads, file uploads, even environment variables and config pulled from a third-party service — and ask what validates it, and whether that validation actually runs before the data is used, not just before it's stored.
Once you've mapped your Data Flow Diagram, trust boundaries fall out naturally: draw a line anywhere a data flow crosses from a zone with one set of trust assumptions into a zone with a different set, and you've found one.