A password-reset endpoint can work exactly as its developer intended and still expose information. If its response reveals whether an email address has an account, someone outside the system can check which addresses are registered. Threat modeling helps a team spot that risk before relying on code review or testing to catch it.
A threat model is a working account of what needs protection, how the system works, where things could go wrong, and what the team plans to do. It does not predict every attack. For a beginner, a one-page diagram, a short list of plausible threats, and a record of decisions can be enough.
Start with a small, defined system
Consider a study-planner app. A user signs in, creates private tasks, and can receive email reminders. The browser sends requests to an application server, which stores tasks in a database and asks an email provider to send reminders. An administrator can investigate delivery failures but should not need to read task contents.
Model one feature or data flow at a time. “Secure the whole app” is too broad to guide decisions. “Protect task creation and retrieval for signed-in users” gives the team something to draw, question, and test. Record assumptions too: Are accounts open to the public? Who operates the database? Do reminders contain task text? If the answers change, the threats and priorities may change with them.
Identify assets and security goals
An asset is anything whose loss, exposure, or misuse would matter. Here, assets include account credentials, task contents, the ability to change or delete tasks, and the availability of reminders. Security goals spell out what protection means: only a task’s owner should read it; account recovery should not let someone else take over an account; a reminder failure should not erase saved tasks.
These assets do not all carry the same risk. A short reminder delay is different from exposing every user’s tasks. Record that distinction early so the threat list does not become a checklist with no clear priorities.
Draw the data flow and mark boundaries
A basic data-flow diagram shows the people, processes, data stores, and connections involved. Boxes and arrows on paper will do. Draw the user’s browser, application server, database, and email provider. Add arrows for sign-in requests, task reads and writes, database queries, and reminder messages. Label each arrow with the data it carries, not just “API call.”
Then mark trust boundaries: points where data or control moves between parties or environments with different authority. A browser request crosses a boundary because the user controls the browser. A message to the email provider crosses another because the provider is outside the app’s direct control. The server-to-database connection may cross a deployment boundary even if one team operates both.
A boundary does not mean a connection is unsafe. It tells you where to ask who controls the input, what identity the receiving component can verify, and what privileges it uses. A task ID supplied by a browser, for example, does not prove the requester owns that task. The server must establish that relationship.
Ask what can go wrong
Work through each component, connection, and boundary. Describe concrete unwanted outcomes rather than writing “hackers” or “insecure API.” For the planner, plausible concerns include:
- Unauthorized reading: a signed-in user changes a task ID and requests another user’s task.
- Unauthorized change: a request updates a task without an ownership check.
- Information disclosure: reminder emails contain private task text that someone with access to a shared inbox can see.
- Service disruption: repeated reminder requests use up a limited sending allowance.
- Loss of evidence: task deletion leaves too little audit information to investigate an unexpected change.
These are hypotheses, not claims that the app has these flaws. To look for blind spots, ask: Could someone claim another identity? Change data they should not control? See information they should not receive? Make a service unavailable? Gain more authority than their role allows? A named framework can help organize the questions, but descriptions tied to the actual system matter more than memorized categories.
Include ordinary mistakes and failures, too. An email provider outage could delay reminders; a misconfigured administrator role could expose task contents. The security goal matters regardless of whether the cause is deliberate.
State a threat in testable terms
“The API has an authorization problem” does not tell a developer where to look. Try this instead: “A signed-in user may supply a task ID belonging to another account, and the task-read endpoint may return its contents if the server does not check ownership.” That identifies the actor, entry point, condition, and outcome. A developer can inspect the endpoint and write an authorized test with two accounts they control.
Keep a threat separate from a vulnerability. An unauthorized read is a possible outcome; a missing ownership check is a vulnerability only if confirmed. The distinction stops an unverified concern from being recorded as a known defect.
Prioritize without pretending to know exact probabilities
A small team cannot address every plausible failure at once. Rate impact and how readily each threat could arise with simple labels such as high, medium, and low. Consider how much data or functionality is affected, what access someone would need, whether existing controls reduce the risk, and how likely the team is to notice a problem.
An unchecked task-read endpoint could expose private content across accounts. A reminder delay affects availability but may leave saved tasks untouched. Both matter, though the endpoint may come first if the app stores sensitive notes. Write down why you ranked them that way; the label alone explains little.
Be explicit about what you do not know. If no one has confirmed what the email provider retains, record an open question instead of guessing. A local learning project with no real user data has a different immediate impact from a deployed service, though the same design flaw is still worth fixing in the lab.
Choose a response for each important threat
A team can reduce a risk with a control, change the design to avoid it, accept it for a stated reason, or transfer part of the responsibility through a service arrangement. Transfer does not excuse the team from knowing what data it sends or how it handles failures.
For unauthorized task reads, enforce ownership on the server for every task access, then test that account A cannot read account B’s task. To limit disclosure through reminders, send a generic notice instead of task text. If the provider goes down, keep tasks intact, record failed delivery attempts, and show users the reminder status.
Give each chosen response an owner and a way to verify it. “Add authorization” is vague. “The task API owner will enforce ownership on reads and updates; automated tests will cover cross-account requests” is actionable. If the team accepts a risk, record who decided and what would prompt another review. Otherwise, “accepted” can quietly become “forgotten.”
Keep the model connected to changes
The first threat model is a snapshot. Revisit it when the app gains a role, stores a new kind of data, exposes an endpoint, or changes providers. Shared task lists, for example, would change the planner’s model: ownership alone would no longer determine who may read a task, and invitations and removals would need their own review.
Threat modeling does not replace secure implementation, code review, or authorized testing. It helps direct that work. An assumption can survive a neat diagram without being checked, and a control written down can fail in code. Keep the diagram and threat list near the project so developers can update them as features change.
For a first exercise, take the planner’s task-read flow and write down five fields: asset, boundary, unwanted outcome, planned control, and verification. For verification, use two test accounts you control: while signed in as account A, request a task belonging to account B. The server must not return the task contents.
