Data Flows, Entry Points, and Trust Boundaries

By the end of this lesson, you will be able to...

• Trace the important data and decisions in a small sharing feature from one actor to the next.

• Identify entry points and mark where the system changes its trust or control assumptions.

• Improve an incomplete data-flow diagram so it can support later threat discovery.

Idea in one sentence: A data-flow diagram is useful for security when it shows not only boxes and arrows, but also what enters, what moves, who decides, and where the system must stop assuming the other side is under the same control.

Core Insight

ShareBox lets an employee send a renewal proposal to an external partner. The team has already agreed that the proposal, sharing link, recipient details, and revocation record matter.

Someone draws the architecture on a whiteboard:

Employee  →  ShareBox  →  Partner

It is not false. It is also too small to answer an important question: after the employee revokes a link, which part of the system decides that the partner can no longer download the proposal?

The line labeled “ShareBox” hides a browser, an API, a metadata record, an email service, a download endpoint, and document storage. Some pieces make decisions. Some only carry data. Some are outside the team’s direct control. If they remain hidden, a later threat discussion has to guess where access is checked and where a sensitive value can escape.

The useful next step is not a more decorative architecture diagram. It is a data-flow view: a deliberately simplified map of entities, processes, data stores, and the data that moves between them.

The First Diagram Hides the Decisions

The first reasonable model is:

A security diagram only needs to show the main services and network connections.

That model can be enough for capacity planning or a product overview. It becomes insufficient when a security promise depends on a decision made at one point in the path.

Suppose ShareBox writes revoked=true in its metadata database. If the download endpoint does not read that record before returning the file, the revocation record can be perfectly correct and the promised outcome still fails. The interesting fact is not merely that “data flows through ShareBox.” It is that a request enters at a particular endpoint, crosses a boundary from an external browser, and reaches a decision that must consult the current access state.

The missing model must answer four practical questions:

1. What flows? A document, a recipient address, a sharing link, a download request, or an access decision are different things.
2. Where can something enter? An entry point is a place where an actor or another system can supply a request, data, or command.
3. Who makes which decision? A process can create a record, send a message, check expiry, or return a document.
4. Where does trust change? A trust boundary is a point where the assumptions, authority, or control of one side are not the same as the other side’s.

The Small Situation

For this lesson, ShareBox is a simplified teaching model. The team operates the Sharing API, the metadata database, the download endpoint, and the object store. It relies on an external email provider to deliver a message to the partner. The partner is not a ShareBox employee and may use any browser.

The feature has two related flows:

• Create and send: an employee uploads the proposal, enters the partner’s email address, and asks ShareBox to create a time-limited share.
• Download: the partner opens the email, follows the sharing link, and asks ShareBox for the proposal.

Those flows are small enough to inspect, but they already expose several different kinds of value from lesson 002: proposal contents, the sharing capability, recipient data, and the current revocation state.

The Moving Parts

Before drawing arrows, name each part by its role. The names need not match a production service name. They must make the analysis understandable.

This distinction matters. A data store does not normally make an authorization decision by itself; it supplies state that a process interprets. An email provider delivers a link but does not become the authority that grants access merely by delivering it.

What the Diagram Must Make Visible

Here is a compact data-flow diagram. The labels are intentionally specific enough to be questioned later.

 [Employee browser]
       | upload proposal + recipient + requested expiry
       v
 +------------------- ShareBox-operated boundary -------------------+
 | [Sharing API] ---- write share record ----> [Metadata database]  |
 |      |                         |                                 |
 |      | store proposal          | share_id, expiry, revoked       |
 |      v                         |                                 |
 | [Object store]                 |                                 |
 +------|-------------------------|---------------------------------+
        | deliver email: share link|
        v                          |
 [Email provider]                  |
        | email with share link    |
        v                          |
 [Partner browser] -- GET /share/<link> --> [Download endpoint]
                                              | read current state
                                              v
                                       [Metadata database]
                                              | if allowed, fetch document
                                              v
                                       [Object store]

The diagram is a teaching model, not an assertion that every production deployment has exactly these components. It leaves out load balancers, encryption details, caches, and observability systems because they do not yet change the reasoning. If a cache can serve a document after revocation, it would become relevant and belongs on a later revision of the diagram.

Trace the Download, Not Just the Arrow

The download flow is where the earlier simplified diagram becomes useful or useless. Start with a link that is valid at 09:00 and is revoked by the employee at 09:05. At 09:06 the partner opens it.

The exact rule is illustrative. A real product may require an authenticated recipient, one-time links, a separate authorization service, or more conditions. The lesson’s point is earlier and more general: show the request, the current state, the decision, and the resulting data movement. Otherwise nobody can inspect whether revocation is real or merely a field in a database.

So far

We have turned “partner downloads a file” into a visible sequence: external input, state lookup, decision, and possible data release. This matters because later threat discovery can ask what can go wrong at a named element or crossing instead of asking vaguely whether “ShareBox is secure.”

Entry Points Are More Than Login Screens

An entry point is any place where an actor or system can introduce a request, command, or data into the modeled system. It is not limited to an HTML login form.

For the ShareBox feature, useful entry points include:

Listing an entry point does not accuse it of being vulnerable. It gives the team a place to ask a focused next question. In lesson 006, for example, an abuse case can start at a specific entry point and follow a specific path rather than beginning with a generic “attacker attacks the system.”

Where Trust Changes

A trust boundary is not simply a line around every server or every network hop. It marks a change in what the team can safely assume about identity, authority, behavior, administration, or data handling.

In this example, three boundaries deserve explicit attention:

The metadata database and object store are inside the team-operated boundary in this simplified model. That does not mean they are automatically trusted for every purpose. If they are separately administered, supplied by another tenant, or reachable through a different identity model, a more detailed analysis may draw another boundary. Boundaries are claims about control and assumptions, not decoration inherited from a cloud icon.

What This Changes

Before this diagram, the team might say, “The partner receives a link from ShareBox.” After tracing the flow, it can say something more useful:

An external browser presents a sharing link to the download endpoint. The endpoint reads the current expiry and revocation state before it can return proposal bytes.

That sentence creates an inspectable security claim. It points to the decision, its inputs, and the protected output. A later session can challenge each part: Is the state fresh? Is the endpoint truly the only download route? Does another flow bypass the revocation decision? Those are threat-model questions grounded in a system representation, not generic control advice.

Cost, Limits, and Signals

The trade-off is clarity versus maintenance and cognitive load. Drawing flows buys clarity, but it costs time and attention. A diagram that includes every container, library, and monitoring topic becomes difficult to read. A diagram with only one large ShareBox box hides the decisions that need review.

For an early model, choose the level of detail that can answer the next question. Here, the team needs to reason about access, expiry, and revocation, so the download endpoint and metadata lookup earn separate places. It does not yet need a diagram of storage encryption internals; that belongs to a different question and possibly a different track.

This model can still fail when it becomes stale. A useful signal is a feature change that adds a new route, data store, dependency, cache, or way to retrieve the proposal. If ShareBox adds “download a ZIP of all shared documents,” the old diagram no longer supports the claim that every release of proposal bytes goes through the shown decision.

Common Confusions

• “A data-flow diagram is an architecture poster.” It is a focused representation of interactions and data. Its job is to reveal the path relevant to the question, not to document every deployment detail.
• “Every arrow is a trust boundary.” An arrow shows movement. A boundary marks a change in assumptions or control. Several arrows may cross one boundary, and an internal arrow may matter without crossing one.
• “The email provider authorizes downloads.” Delivering a link and deciding whether a link is currently valid are different jobs. In this model, the download endpoint decides.
• “An entry point is automatically a bug.” It is a place to inspect. The model lets the team ask the right question before deciding whether a threat exists.

Check Your Understanding

Check: The employee revokes a share, but a separate preview service can still retrieve the proposal directly from object storage. What is missing from the diagram or model?

Think first, then reveal.

Answer: The preview service and its flow to object storage are missing. The team cannot claim that revocation protects all release paths until it knows whether that service reads and enforces the same current access state.

Check: Is the arrow from the Sharing API to the metadata database necessarily a trust-boundary crossing?

Think first, then reveal.

Answer: Not necessarily. In the simplified model both are operated by the same team, but the answer depends on their administration and identity assumptions. The arrow is important because state moves; a boundary is justified only when control or assumptions change.

Practice: Repair the Diagram

A team presents this model for a customer-support export feature:

Support agent → Export service → CSV file → Customer

Improve it before discussing threats. Add the smallest set of entities, processes, stores, flows, entry points, and trust boundaries needed to answer: “Can a revoked support agent still obtain an export?”

A good answer should include:

• a request from the support agent to a process that makes an access decision;
• the current role or revocation state and where that state is read;
• the data store that supplies customer data;
• the path by which the CSV reaches the customer or another external system; and
• a marked point where an external actor or separately controlled service crosses into the modeled system.

Do not start by choosing authentication products or exploit techniques. First make the decision path visible enough that the later questions have a concrete target.

Connections

• Lesson 002 named the proposal, sharing link, recipient data, and revocation record that these flows must protect.
• Lesson 004 will ask you to review the scope, assets, assumptions, flows, and boundaries together before the track introduces adversary profiles.
• Lesson 006 will use a named entry point and a visible sequence to turn an objective failure into an abuse case and attack path.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Use its system-modeling guidance to check that a diagram shows entities, processes, data stores, flows, and trust boundaries.
• [PROJECT] OWASP Threat Modeling Project — Focus: Use the “what are we building?” question to keep a diagram tied to scope and data-flow transitions.
• [LEARNING PATH] Microsoft Threat Modeling Security Fundamentals — Focus: Use it for another guided pass through data-flow elements and threat-modeling fundamentals.

Key Takeaways

• A useful data-flow view shows external entities, processes, data stores, and labeled movement, not just service names.
• Entry points identify where requests, commands, or data enter the modeled system; they are prompts for investigation, not automatic defects.
• Trust boundaries mark changing control or assumptions, not every network arrow.
• Trace the request, state lookup, decision, and protected output so future threat discussions can challenge a real path.