Why You Need a Map Before You Hunt
You cannot systematically apply STRIDE to a system you have not drawn out. Data Flow Diagrams (DFDs) are the standard visual tool used in threat modeling to represent how data moves through a system. They are deliberately simple — not UML, not sequence diagrams — because the goal is to identify trust boundaries, not document implementation details.
The Four DFD Elements
| Symbol | Element | What It Represents |
|---|---|---|
| Rectangle | External Entity | A person or system outside your control (e.g., a user's browser, a third-party payment API). |
| Circle / Oval | Process | Code that transforms or acts on data (e.g., your web server, an authentication service). |
| Parallel lines | Data Store | Anywhere data is persisted (e.g., a database, a file, a cache). |
| Arrow | Data Flow | Data moving between elements (e.g., an HTTP request, a database query). |
Trust Boundaries
The most important concept in a DFD is the trust boundary — a line that separates zones of different trust levels. Data crossing a trust boundary is where most vulnerabilities live. Common trust boundaries include:
- The internet (untrusted) → your load balancer (trusted)
- Your application server → your database (different privilege level)
- A container → the host OS kernel
- One microservice → another microservice (even inside the same cluster)
Every data flow that crosses a trust boundary should be scrutinized with STRIDE. Data flows that stay within a single trust zone are lower priority.