Chapter 2 · Practice 1 of 4

Draw a data flow diagram with the standard elements

From What are we working on: diagrams and trust boundaries

Why it matters

The OWASP cheat sheet calls data flow diagrams (DFDs) the most common way to model a system for threat modeling. A DFD shows what talks to what and where data goes, using a small set of elements:

Element	What it is	Examples
External entity	something outside your control that sends or receives data	user, browser, partner API, payment provider
Process	code you run that handles data	API server, worker, Lambda, LLM agent loop
Data store	where data rests	Postgres, S3 bucket, Redis, vector index, logs
Data flow	data moving between elements, labeled with what and how	"login request, HTTPS", "job payload, SQS"
Trust boundary	a line where the level of trust changes	internet to your VPC, your app to a third party

OWASP says these are typically where attacks happen, so a diagram that shows them gives the next step something to work with.

Tips that keep diagrams useful:

Label flows with the data and protocol, not just an arrow.
Start with a high-level view, and add detailed diagrams only for complex parts, as OWASP suggests.
Include the boring parts: logs, backups, admin panels, CI/CD and support tools. Those are often the weak paths.
Draw what is built (or will be), not the ideal architecture from a slide.

Example

Code

flowchart LR
  user([Customer browser]) -- "checkout form, HTTPS" --> api[Orders API]
  subgraph vpc [Trust boundary: our VPC]
    api -- "SQL, TLS" --> db[(Orders DB)]
    api -- "job, SQS" --> worker[Invoice worker]
    worker -- "PDF" --> s3[(Invoices bucket)]
  end
  api -- "charge request, HTTPS" --> psp([Payment provider])
  psp -- "webhook, HTTPS" --> api