Data Flow Diagrams and Trust Boundaries

You cannot find threats in a system you do not understand. A Data Flow Diagram (DFD) is the foundation of threat modeling: it visually maps how data moves through your system.

The diagram makes implicit assumptions explicit. Once you can see where data goes and who touches it, threats become far easier to spot.

A DFD uses just four building blocks. Keep them simple:

• External entity — a person or system outside your control (user, third-party API)
• Process — something that transforms data (a service, a function)
• Data store — where data rests (database, file, cache)
• Data flow — the movement of data between elements (an arrow)

Almost any system can be represented with these four shapes.

DFDs use conventional shapes so anyone can read them:

Consider a basic web application. Its DFD might look like this in text form:

A trust boundary is any line in your diagram where the level of trust changes. On one side, data or callers are trusted; on the other, they are not.

Trust boundaries are the most security-relevant feature of a DFD because they mark where:

• Data should be validated
• Callers should be authenticated and authorized
• Privilege levels change

Most vulnerabilities live exactly where data crosses a trust boundary.

Once you start looking, trust boundaries are everywhere. Common examples:

• The internet to your application (untrusted user input arrives)
• The application to the database
• Between a low-privilege and high-privilege process
• Between your system and a third-party API
• Between a container and the host
• Across network segments (DMZ to internal)

Each boundary deserves explicit scrutiny.

Add trust boundaries as dashed lines that cut across the data flows they affect. In our web app:

Trust boundaries connect this lesson to STRIDE. The data flows that cross a boundary are where you focus your STRIDE analysis.

At the internet-to-app boundary, ask:

• Spoofing — is the caller authenticated?
• Tampering — is input validated?
• Information disclosure — is the channel encrypted?
• Denial of service — is there rate limiting?

Boundaries turn an abstract framework into concrete questions.

A DFD can be too vague or too detailed. Both fail.

• Too high level — one box labeled 'the system' hides all the interesting boundaries
• Too detailed — every function and variable, drowning you in noise

Aim for the level where each major component and trust boundary is visible. Use layered DFDs: a context diagram for the whole system, then drill into complex processes separately.

A DFD drawn by one person usually contains wrong assumptions. Walk through it with the people who built the system.

Ask probing questions:

• Is this really the only way data reaches the database?
• Are there admin or batch paths not shown here?
• Does anything bypass this authentication step?
• Are there cached copies of this data elsewhere?

Hidden data flows are a frequent source of missed vulnerabilities.

Systems change, and a stale DFD becomes misleading. An outdated diagram is worse than none because it creates false confidence.

Update the DFD when:

• A new integration or external dependency is added
• A new data store appears
• The trust model changes (a service moves to a new network zone)

Treat the DFD as documentation that lives alongside the system, not a one-time artifact.

Test your understanding of DFDs and trust boundaries.

You learned to map systems for threat modeling:

• A DFD uses four elements: external entities, processes, data stores, and data flows
• Trust boundaries mark where trust changes and where most vulnerabilities live
• Data flows crossing a boundary are where you focus STRIDE analysis
• Choose the right granularity and use layered diagrams
• Validate the DFD with the team and keep it current

Next, you will rank threats with attack trees and prioritize mitigations.