Data-flow diagrams and trust boundaries

The four elements of a data-flow diagram

STRIDE gives you the kinds of threat — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. But STRIDE applied to “the system” is a fog. To make it systematic you first need a model of how data actually moves, and the standard model is the data-flow diagram (DFD). A DFD is deliberately tiny — it has exactly four element types, and every box on your whiteboard is one of them:

• External entity — an actor outside your control that sources or sinks data: a browser, a mobile app, a partner’s API, a human. You don’t run their code; you can only validate what they hand you. Drawn as a rectangle.
• Process — code you run that transforms data: an API server, a Lambda, a background worker, a parser. This is where logic — and therefore most bugs — lives. Drawn as a circle.
• Data store — somewhere data rests: a Postgres table, an S3 bucket, a Redis cache, a log file, a message queue at rest. Drawn as two parallel lines.
• Data flow — the arrow connecting any two of the above: an HTTP request, a SQL query, a Kafka publish. The flow carries the data, and the flow is what an attacker observes or manipulates in transit. Drawn as a directed edge.

That’s the whole vocabulary. The power isn’t in the boxes — it’s in being forced to draw every arrow, because each arrow is a place where data is exposed, and each box is a place where data is trusted or transformed. A DFD you can’t draw is a system you don’t actually understand.

Trust boundaries: where the threats live

Now overlay the one annotation that turns a DFD from documentation into a threat-modeling tool: the trust boundary. A trust boundary is a line you draw across data flows wherever data passes from one principal, privilege level, or ownership domain into another. Concretely, a boundary sits at every point where the answer to “who controls the data on this side?” changes:

• Between a browser and your API (untrusted client → your code).
• Between your API process and your database (application privilege → data privilege; a SQL injection here is a boundary crossing).
• Between your code and a third-party service (your data leaving your control).
• Between two of your own microservices when they run at different privilege or trust levels.
• Between a low-trust DMZ process and a high-trust internal one.

The reason boundaries matter so much is statistical as much as conceptual: threats concentrate at crossings. Data that never leaves a single trust zone is comparatively safe — it’s already inside one principal’s control. The dangerous moments are the handoffs, because that’s where one side must decide whether to trust the other, and a wrong decision is the vulnerability. Spoofing happens crossing into your auth boundary; tampering and disclosure happen on flows crossing a boundary; elevation of privilege happens when a process on the trusted side accepts input that should have been treated as untrusted. The boundary is the address where each STRIDE letter comes to collect.

Attack surface: the sum of every crossing

Once boundaries are drawn, the attack surface falls out of the diagram almost for free. Attack surface analysis, in OWASP’s framing, is the work of enumerating every point where an attacker can try to enter data into or extract data from your system — and on a DFD those points are precisely the data flows that cross a trust boundary. Every such crossing is an entry or exit point: a login form, an API endpoint, a file upload, a webhook receiver, an outbound call to a third party, a queue your code consumes from.

The senior move is to treat attack surface as something you measure and shrink, not just inventory. The cheat sheet’s guidance is blunt about the tradeoff: more entry points, more privileged code, and more trusted external dependencies all enlarge the surface, and the surface — not your lines of code — is what an attacker actually probes. So you ask, per crossing: does this endpoint need to exist? Can it require authentication? Can it run with less privilege? An endpoint you delete is an endpoint that can’t be exploited; an internal service you make unreachable from outside removes a whole boundary from the attacker’s map. Surface reduction is the cheapest control you own because it removes the threat instead of mitigating it.

From DFD to STRIDE-per-element

Here’s the payoff that makes the diagram worth drawing: STRIDE-per-element. Instead of brainstorming threats freeform, you walk the DFD methodically and apply only the STRIDE letters that each element type can actually suffer. The element type tells you which letters are even in play, which collapses an open-ended brainstorm into a finite, reviewable checklist:

• External entities are susceptible to S and R (spoofing, repudiation) — can someone impersonate this actor, and can the actor deny an action?
• Processes can suffer the full STRIDE set — they’re the richest target, especially T, I, and E (tampering, disclosure, elevation).
• Data stores are mainly exposed to T, R, I, D (tampering, repudiation if logging is weak, disclosure, denial of service).
• Data flows are exposed to T, I, D (tampering, disclosure, denial) — which is exactly why a flow crossing a boundary deserves TLS, integrity checks, and rate limits.

You apply this most rigorously at the boundary crossings. A data flow that stays inside one trust zone still gets reviewed, but a flow crossing a boundary is where tampering and disclosure are most likely and most damaging, so it earns the deepest scrutiny. The DFD plus boundaries plus the element-type-to-STRIDE mapping is the entire engine: it turns “what could go wrong?” — a question that produces panic or hand-waving — into “for each element, which of these specific letters apply, and is the crossing controlled?”

Failure mode: the boundary you didn’t draw

The recommendations incident from the hook is the canonical DFD failure, and it has a name worth internalizing: the missed trust boundary. It almost never looks like incompetence. The team did STRIDE; they just modeled the system as deployed intentions rather than actual reachability. The internal service was “internal,” so they drew it inside the trusted zone, so it sat on no boundary, so STRIDE-per-element never asked “can this caller be spoofed?” — and the control that question would have demanded (authenticate every caller, least privilege) was never built.

The discipline that prevents it: draw boundaries where data can actually cross, not where you intend it to cross. Every time you place a box inside the trusted zone, ask the adversarial question — “what if this is reachable from outside?” — and verify the reachability against real config (ingress rules, security groups, service mesh policy), not the architecture slide. A network you assume is segmented but never verified is a flat network with extra steps; the classic SSRF-to-metadata attack (a server tricked into fetching http://169.254.169.254/) is precisely an attacker using your own process to cross a boundary you assumed they couldn’t reach. The boundary on the diagram is a claim about the world. If you haven’t verified the claim, you haven’t drawn a boundary — you’ve drawn a wish.