Threat modelling a small web app: STRIDE without the ceremony

Draw the app on one page first: the browser, your API, the Supabase database, Stripe and the AI provider, with an arrow wherever data crosses between them. That sketch answers the first question of threat modelling, what are we working on. The other three follow at each arrow: what can go wrong, what to do about it, and whether the work was good enough.

What is threat modelling? Four questions, asked before an attacker asks them

Threat modelling is a structured review of a system’s design that asks four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. For a small app the output is a one-page diagram and a ranked list of threats with owners.

The controls that come out of it land in layers of the app, and where each layer sits is the wider subject of web app security.

The definition I work from: a threat model is a structured look at your app’s design to find what could go wrong and decide what to do about it, before a customer, a reviewer or an attacker finds it the hard way. The Threat Modeling Manifesto puts it more formally, “Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics,” and credits the four questions to “Shostack’s 4 Question Frame for Threat Modeling.”

Threat modelling and threat modeling are the British and American spellings of the same thing, with the same definition in cyber security writing on both sides of the Atlantic; the rest of this page uses the American one.

Each question has an output, and for a two-person team my working rule keeps each output small enough to finish in a sitting:

1. 01 What are we working on? Output: a one-page data flow diagram of the app as it is deployed
2. 02 What can go wrong? Output: a list of threats, each written as one sentence naming the attacker, the action and the asset
3. 03 What are we going to do about it? Output: a ranked short list, with one owner for each item
4. 04 Did we do a good enough job? Output: the checks you ran, their results, and a date to look again

A threat model is that diagram plus that list. It is not a document genre, and nobody needs a template to have one. That is also the most useful threat model definition for a founder, because it tells you when you are done.

Among the other parts of cybersecurity, a threat model is the one that works on a design before it ships. In my reading, the neighbors split cleanly: a penetration test attacks what is built, a scanner matches known patterns in code and dependencies, and a threat model questions the design itself.

Why it matters for a small SaaS: the app threats no scanner reports

The purpose of threat modeling is to find design flaws: application threats that a scanner or a linter may not report, because no single line of code is wrong. The route works, the query runs, the tests pass, and the design still lets the wrong person do the wrong thing.

Three rows from my June and July 2026 audits show the shape of it: the apps I audited are a selected set, 21 third-party apps, of which the 14 with an AI feature are the base for the AI row, not a random sample, so read the rows as what can happen rather than as a rate for AI-built apps in general.

The letters in the third column are my reading. Each row was a question nobody asked at design time. My reading of why: these apps were built from prompts that described features, not abuse, and nothing in that kind of build asks who else might call the route or what one account could cost.

The OWASP Top 10 has a category for exactly this gap. A06:2025 Insecure Design “focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures.” A dated threat model is the evidence for that category when you work through how to test the OWASP Top 10 vulnerabilities on your own app.

When to do it, as my working rule: before launch, and again whenever the app gains a new kind of data, a new provider, or a way to move money.

How it works: STRIDE on a one-page data flow diagram

The diagram needs five shapes. Microsoft’s 2006 article on STRIDE uses a standard set of data flow diagram symbols “consisting of four elements: data flows, data stores, processes, and interactors,” and says that “for threat modeling we add one more”: the trust boundary, drawn as a dotted line. Later Microsoft writing calls interactors external entities. On a small app they map like this: external entities are the people and services you do not run (the user’s browser, Stripe, the model provider); processes are your API routes and server functions; data stores are your Supabase tables and storage buckets; data flows are the arrows; a trust boundary is any line where you stop controlling what arrives.

Draw it on paper or a whiteboard and photograph it. The sketch is disposable; a maintained diagram that stays true to the deployed system is a different artifact, and how to create architecture diagrams that last is its own job.

The rest of the afternoon runs in the order of the headings below: the categories, the grid, a worked example, ranking, the other methods you’ll hear named, how the result feeds a risk assessment, and the tools.

What is STRIDE? The six categories, with an example of each

The STRIDE threat model is a mnemonic that came out of Microsoft: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Each letter names a threat to one property a system should have, from authentication to authorization. STRIDE prompts the question of what can go wrong; it is not a grading scheme.

Microsoft dates STRIDE to 1999, when two of its employees, Loren Kohnfelder and Praerit Garg, wrote a document called “The threats to our products,” which Microsoft says “introduced the STRIDE approach, a synonym for the Microsoft threat modeling process.” The STRIDE acronym stands for those six threat categories. Microsoft’s STRIDE threat categories page describes the six, and Microsoft’s 2006 article pairs each with the property it violates.

The first three columns below are Microsoft’s; the example and control columns are my reading, each one an example of STRIDE on a small app.

The property column is the useful half for cybersecurity work that has to end in a fix: a spoofing threat needs an authentication control, a tampering threat an integrity check, and so on down the rows. What STRIDE adds to cyber security practice is timing: it runs at design time, before any scanner has code to read.

Used as a threat modeling framework or methodology, STRIDE is a checklist for a design review, and it forgives filing mistakes: a threat put under the wrong letter is still found. The 2006 article says the same about one of its own examples: “Don’t get too hung up over the terminology.”

STRIDE per element and the STRIDE matrix: which letters apply to which shape

STRIDE per element walks a data flow diagram one shape at a time and asks only the letters that apply to that kind of shape. In Microsoft’s chart, processes get all six letters, data flows and data stores get three each, and external entities get two. That grid is the STRIDE matrix.

Microsoft’s STRIDE-per-element article prints the chart as “Threats Affecting Elements”. Here it is with its rows in the order you’ll meet them on a small app.

One exception is worth adding to the data store row. Adam Shostack’s 2008 paper on threat modeling at Microsoft, which names the technique “STRIDE per element,” adds: “For data stores which are logs, we are concerned with repudiation issues, and attacks on the data store to delete the logs.” On a small app that means the audit log table gets the repudiation question too.

The STRIDE-per-element approach helps a small team because it turns a blank page into a short list of yes-or-no questions. A process asks six, a flow or a store asks three, and an outside party asks two, so a five-shape diagram with a handful of arrows gives you a list you can finish.

The other variant works one step finer. In Microsoft’s Threat Modeling Tool, each generated threat is shown against an interaction between two elements. In my reading, that is the STRIDE-per-interaction way to walk the same grid.

A threat matrix in this page’s sense is that grid; the same two words also name a TV series, an online-abuse monitoring service and an insider-threat framework, none of which is this. MITRE ATT&CK’s matrix is a different tool again: “a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations,” a catalog of attacker techniques rather than a grid of design elements.

A STRIDE threat model example: a Supabase and Stripe app with one AI feature

A STRIDE threat model example for a small SaaS fits in about a dozen rows: five elements, six data flows and three trust boundaries, with each threat written as one sentence naming the attacker, the action and the asset. Drawing, walking the grid, ranking and writing tickets take about an afternoon, by my working rule.

This STRIDE analysis is constructed from patterns in my audits, not a record of one app. The assumptions: a Next.js app on a managed host, Supabase for auth and data, Stripe Checkout and webhooks, one endpoint that calls a model provider, two roles (member and admin), built with an AI builder.

The diagram in words. Five elements: the browser (external entity), your API routes (process), the Supabase database (data store), Stripe (external entity) and the model provider (external entity). Six flows: browser to API, browser to the Supabase data API, API to database, browser to Stripe Checkout, Stripe to your webhook route, and API to the model provider. Three trust boundaries: between the browser and anything you run, between your API and the database, and between your API and third parties.

The present-or-not column is part of the constructed example, there to show that the list mixes real gaps with rows you check and close. Row 6 is the one AI-specific threat here; what prompt injection is, and how it reaches data, is a subject of its own. Rows 2, 4 and 9 all live in API routes, and checking each route against them properly is an API security assessment.

Six rows match patterns counted in those same audits. Row 1 is the cross-user and cross-tenant failure (7 of the 21 third-party apps) and row 5 the denial-of-wallet path (12 of the 14 AI apps), both in the first table. Rows 2, 4 and 9 are one pattern: 10 of the 21 third-party apps trusted the client, and the server accepted whatever the browser asserted. Row 8 is a leaked credential: 6 of the 21 third-party apps shipped a real secret. Those counts come from the same chosen group of apps, so they tell you what turns up, not how often. The other rows carry no count because I have none for them.

My working rule for the time: about 30 minutes to draw, about 90 to walk the grid, about 30 to rank and about 30 to write the tickets. STRIDE examples like this one are only useful if they end in tickets, so the last half hour is not optional.

Ranking what you found: the DREAD model, DREAD scoring, and the simpler rule

The DREAD model ranks threats on five factors: damage, reproducibility, exploitability, affected users and discoverability. The scores are judgment calls written as numbers. By my working rule, a small team can rank twenty threats with two questions instead: how bad is it if it happens, and how easy is it for a stranger with a browser?

Microsoft’s driver-security guidance still prints the recipe for a DREAD score: “rank each threat from 1 to 10 on all 5 of the DREAD assessment criteria, and then add the scores and divide by 5 (the number of criteria),” and “High scores indicate serious threats.”

The history is the reason I skip DREAD scoring. Adam Shostack, a co-author of the 2006 STRIDE article, wrote in a 2008 paper on threat modeling at Microsoft that DREAD “seems to add numbers without defining their scales, generating a risk of making a risk assessment appear algorithmic when it’s not.” In a 2018 post he describes the trouble of running DREAD beside a second way of ranking bugs reported from outside, and says: “This happened to Microsoft repeatedly, and led to the switch to a bug bar approach.” In a DREAD threat model, two people can give the same threat different scores; in his words, “Without calibration, different raters will not be consistent.”

My working rule for twenty threats: sort by the two questions above, how bad (money, customer data, downtime) and how easy for a stranger, then take the top five. That is a DREAD risk assessment with the arithmetic removed.

DREAD threat modeling (DREAD threat modelling, in British spelling) is for ranking design threats. Known vulnerabilities in your dependencies are a different problem: they get a CVSS score rather than a DREAD risk score, and that work belongs with vulnerability management tools. At this size, the two questions replace the whole DREAD framework, and if a customer’s questionnaire asks how you rank threats with DREAD, the dated list ranked by those two questions is an honest answer.

Every ranked threat then gets one of four answers, as my working rule: mitigate it, eliminate the feature, transfer it to a provider that handles it, or accept it in writing with a name and a date.

STRIDE alternatives: PASTA, LINDDUN, Trike, STRIDE-LM, and the OWASP and NIST guidance

STRIDE alternatives exist for bigger programs and other goals. PASTA is a seven-stage, risk-centric method tied to business objectives. LINDDUN targets privacy threats. Trike builds a matrix of actors, assets and actions. STRIDE-LM adds lateral movement for network defenders. OWASP teaches the four questions, and NIST’s data-centric guide is still a draft.

Each threat modeling method in the table comes from its own source; the team-size column is my reading. Every row is one of the cyber security threat models built for a different job, from privacy to network defense.

PASTA threat modeling runs as a program. The book that introduced it, “Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis,” came out from Wiley in May 2015. VerSprite, a security firm, lists the seven stages of the PASTA threat modeling framework as define business objectives, define technical scope, application decomposition, threat analysis, vulnerability analysis, attack simulation, and risk analysis and mitigation, and calls PASTA “a risk-driven threat modeling methodology that treats cyber threat mitigation as a business problem first.” PASTA modeling is worth knowing by name; it is rarely worth running on a product with two engineers.

LINDDUN describes itself as “a recognized privacy threat modeling framework, developed by privacy experts at KU Leuven.” If your app holds health, location or children’s data, its seven categories are a useful second pass after STRIDE.

A Trike threat model starts from a requirements model. The 2005 Trike v1 methodology document describes an “actor-asset-action matrix” whose columns “represent the assets in the system” and whose rows “represent the roles that actors can take on,” with each cell split into create, read, update and delete. The tool’s GitHub repository calls its current code “extremely pre-alpha code you are welcome to use for research purposes, but should not rely on.” Trike threat modeling is mostly of historical interest for a small team.

STRIDE-LM comes from network defense. csf.tools reports that “Practitioners at Lockheed Martin noted that STRIDE was developed primarily to address engineering and development projects, rather than network defense,” and added a seventh letter for lateral movement, “Expanding control over the target network beyond the initial point of compromise.”

Attack trees sit beside all of these rather than replacing them. Microsoft’s driver guidance describes a threat tree as a diagram where “The ultimate goal of the attack is at the top of the tree,” with each level below it a step toward that goal. Use one to expand a single row of your list that you do not yet understand.

For an OWASP threat model, the practical guide is OWASP’s Threat Modeling Cheat Sheet, which teaches the same four questions and a STRIDE table, and OWASP’s threat modeling process page adds that “using qualitative values, rather than numeric ones like in the case of the DREAD model, help avoid the ranking becoming overly subjective.” In the OWASP Top 10, A06:2025 Insecure Design tells teams to “Use threat modeling for critical parts of the application such as authentication, access control, business logic, and key flows.”

The NIST threat model guidance is NIST SP 800-154, “Guide to Data-Centric System Threat Modeling,” which treats threat modeling as “a form of risk assessment that models aspects of the attack and defense sides.” It is still the initial public draft from March 2016, and a NIST note dated January 23, 2025 says “NIST plans to finalize this publication.”

British guidance spells it threat modelling, and the UK’s National Cyber Security Centre names more than one methodology on its threat modelling page: STRIDE, attack trees, and “the 14 attacker technique groupings from the MITRE ATT&CK framework.” The framing matches across the Atlantic: the NCSC files threat modeling under risk management, NIST’s draft treats it as a kind of risk assessment, and the OWASP Top 10 calls for more threat modeling under its design-risk category.

STRIDE vs PASTA, in my reading: STRIDE is a question prompt you can finish in an afternoon, while PASTA is a seven-stage program that assumes a security team and a business-impact analysis. For a small web app, STRIDE per element is enough, and the other threat modeling methodologies are vocabulary for when a reviewer names one. None of these cybersecurity threat models replaces the four questions; each answers them for a different kind of system.

Threat and risk assessment: how a threat model feeds an application risk assessment

Threat and risk assessment covers two steps. The threat model lists what can go wrong in the design. The risk assessment weighs each item by likelihood and impact, records a decision to mitigate, eliminate, transfer or accept, and names an owner and a date. The first feeds the second.

Three names that come up around SOC 2, gap assessment, readiness assessment, risk assessment, are three different jobs, and a threat model feeds only the last.

My working rule for what an application risk assessment for a small SaaS contains: the ranked threat list, the decision on each item (one of the four answers above), the owner, the date, and the accepted risks signed by whoever owns the business. When a customer’s questionnaire asks for a risk assessment, the honest artifact is that dated list, not a purchased template.

Application security risk management at this size is re-running the model whenever one of the three re-run triggers above fires. The risks you accept do not vanish; how the other layers absorb them is the idea behind defense in depth.

STRIDE GPT and the threat modelling tools: what they do, and what they cannot know

STRIDE GPT is an open-source tool that asks a language model for a STRIDE threat list from a description of your app. Microsoft’s Threat Modeling Tool and OWASP Threat Dragon generate threats from a drawn diagram. All three give you a first pass, and none of them can confirm how your deployed app behaves.

Microsoft’s Threat Modeling Tool is the STRIDE threat modeling tool from the method’s home, a free Windows download: you draw the diagram, open the analysis view, and it lists threats generated from its template using STRIDE per element.

OWASP Threat Dragon is “a free, open-source, cross-platform threat modeling application,” Apache 2.0 licensed, that runs as a desktop app or a self-hosted web app and “implements a rule engine to auto-generate threats and their mitigations” for STRIDE, LINDDUN and other methods.

STRIDE GPT is an MIT-licensed repository by mrwadams. It sends a written description, a GitHub repository or a diagram to the model provider you pick (OpenAI, Anthropic, Google AI, Mistral, Groq, DeepSeek, OpenRouter, or a local model through LM Studio) and returns a threat model, attack trees, mitigations, DREAD scores and test cases. Its own documentation notes that the providers “may log this data per their privacy policies.”

Some builders now generate one for you. Replit documents a paid Security Agent that maps routes and data flows and builds a threat model, which leaves the question of whether Replit’s Security Agent can catch these design flaws in your particular app.

A generated list is good for one thing in my reading: it gets you past the blank page. What it cannot know is what your code actually does at runtime, so check every generated threat against the app before it goes on your list. Do not paste secrets, customer data or code you are not allowed to share into a hosted tool. At this size, a photo of the whiteboard and a spreadsheet are a complete toolset.

How to check your own app: did the model find something real

A threat model has done its job when five things are true: every arrow that crosses a trust boundary has a threat, every threat is one testable sentence, the top five were tested on staging, every row has a decision and an owner, and the diagram matches what is deployed.

This is the fourth question, did we do a good enough job, as five checks you can run on your own system and fail. Each one names the evidence to keep.

1. 01 Every arrow that crosses a trust boundary has at least one threat written against it. Fail: a bare arrow. Evidence: a photo of the diagram with row numbers on the arrows
2. 02 Every threat is one falsifiable sentence naming the attacker, the action and the asset. Fail: a row that only names a class of attack, such as SQL injection. Evidence: the list itself
3. 03 Each of the top five has a test you ran on staging with test accounts, with the expected result written down before you ran it. For a cross-tenant read, sign in as one test tenant and request the other's rows: a correct row level security setup returns no rows rather than an error. For the webhook, post an event without a valid signature: a correct handler rejects it. Never replay a real signed event. Fail: a top-five row nobody tried. Evidence: the request and the response, dated
4. 04 Every row has one of the four answers, an owner and a date, and every accepted risk has a name beside it. Fail: a blank decision. Evidence: the list
5. 05 The diagram matches the deployed system: walk it against the host's settings, the database and the repository, so every element drawn exists and every deployed element is drawn. Fail: a provider or route that is missing. Evidence: the dated comparison

The two expected results in check 3 come from the vendors. Supabase’s row level security guide says a policy that filters a row out “raises nothing, matches zero rows,” and Stripe’s webhook docs say “Always verify that webhook events originate from Stripe before acting on them,” with an example handler that returns a 400 when the signature check fails.

Here is a case where the first two checks fail together. A founder draws the whole backend as one box called “the API,” walks STRIDE over it, and gets back generic lines such as “SQL injection” and “DDoS” that would fit any app and that nobody can test. Redrawn with each route as its own process and the payment webhook as its own data flow across a trust boundary, the grid asks about spoofing of the webhook flow and tampering with the checkout route, and both rows can be tried on staging the same afternoon: an event without a valid signature, and a changed amount in the checkout request. The lesson I take from it is to split the diagram until each threat names one route and one asset, because the level of detail in the diagram decides whether the threats are testable.

Check 5 is also how the Production Hardening Sprint verifies its system architecture diagram, deliverable 13.2: “Compare the diagram with the delivered environment and repository.”

Where the sprint fits

No deliverable in the Production Hardening Sprint is called a threat model; the three closest are these. Deliverable 13.2, the system architecture diagram, shows the deployed components, data flows, authentication boundaries, and third-party integrations. In deliverable 3.7, we review the application against the OWASP Top 10 and record findings, fixes, and evidence by category. Deliverable 3.10 tests the five highest-risk externally reachable attack surfaces, remediates findings, and delivers the methods and evidence. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. Each one, with the check that verifies it, is listed in the published scope.

Common questions about threat modeling

What are the 5 steps of threat modeling?

Microsoft’s Security Development Lifecycle names five steps: defining security requirements, creating an application diagram, identifying threats, mitigating threats, and validating that threats have been mitigated. In my reading they map onto the four questions: the first two answer what you are working on, the third what can go wrong, the fourth what you will do about it, and the fifth whether you did a good enough job.

What is STRIDE in AI?

STRIDE in AI means asking the same six questions of an AI feature’s parts: the prompt, the model call, the tools it can invoke and the data it retrieves. Microsoft’s guidance on threat modeling AI and machine learning systems ties each AI attack back to a familiar threat under the heading “Traditional Parallels”; model inversion, for example, is “Targeted, covert Information Disclosure.” For most small apps, the AI row to write first is prompt injection, row 6 in the worked example above.

Is the Microsoft threat modeling Tool free?

Yes. Microsoft releases its Threat Modeling Tool as “a free click-to-download application for Windows,” and its release notes list Windows 10 Anniversary Update or later, .NET 4.7.1 or later, and an internet connection for updates to the tool and templates.

How can I practice threat modeling?

Practice on an app you know well: draw it on one page, walk the STRIDE grid over each element, then test your top three threats on your own staging copy with test accounts. For a second round, redo the sample system in Microsoft’s 2006 STRIDE article, the Fabrikam analyzer database, and compare your list with the authors’.