Before the exploit, draw the boundary

A diagram can become useful long before it becomes beautiful. For a first security review, a handful of boxes and arrows is often enough to expose an assumption worth investigating.

Start with a system small enough to understand. A browser, an API, and a database are a good example.

Name what matters

For a fictional reading-list app, the assets might be private bookmarks, account sessions, and the ability to change another person’s list. Write down the harm you want to prevent, rather than beginning with a list of vulnerability names.

For example: “A user must not be able to read another user’s private list.” That statement gives the review a concrete target.

Follow one request

Browser → API route → permission check → database query

Describe what crosses each arrow. Is it a session cookie? A user-supplied list identifier? A database result? Who controls it, and what does the next component assume about it?

The browser is outside the server’s enforcement boundary. A value arriving from it needs to be interpreted under server-side rules, even if the normal interface generates that value correctly.

OWASP’s threat-modeling guidance recommends understanding the system, identifying threats, deciding how to address them, and reviewing whether the work is adequate. Data-flow diagrams and trust boundaries help organize that process. OWASP Threat Modeling Cheat Sheet.

Turn assumptions into questions

For this toy application, a useful first pass is:

1. Where does the server establish the current identity?
2. Where does it check access to the requested list?
3. Can a cached response cross between users?
4. What happens after access is revoked?

The questions are deliberately specific. “Is the app secure?” is too large to answer with one diagram or one test.

Keep the model close to the product

Save the diagram beside a short list of assumptions and unresolved questions. When the application adds a public sharing feature, update the model. The meaning of “private list” has changed, and the authorization rules may have changed with it.

A threat model is most useful as a working explanation of the system. It should help someone locate the relevant check, understand why it exists, and choose a test that could show whether it fails.