Threat modeling with STRIDE is the most widely used technique to anticipate the threats to a system before you have built it. In a 45-minute refinement session, a team identifies architectural flaws that automated tools will never detect, because they are design choices, not code bugs. This guide is for DevSecOps teams that want to use STRIDE day to day, not just know it in theory: a 4-step method, asset identification, a complete example on a JWT API covering all 6 threat categories, prioritisation, abuse cases and testable requirements, the place of AI-assisted tools, integration into the agile backlog, and a mini-project to produce your own threat model.
What you will learn
- Understand the 6 STRIDE categories and the technical control associated with each one
- Run a threat modeling session in 4 timed steps
- Identify the assets to protect and the trust boundaries on a minimal Data Flow Diagram (DFD)
- Apply STRIDE end to end on a realistic example of an authentication API
- Place AI-assisted tools within the approach, without handing them the decision
- Turn threats into abuse cases, testable security requirements and CI/CD checks
Why STRIDE and not something else
STRIDE is simple to teach, simple to apply as a team and covers the most common threats in web and Cloud Native systems. Its 6 categories map directly to technical controls that developers already know, which avoids introducing a security vocabulary disconnected from the code.
| Letter | Category | Against what | Associated control |
|---|---|---|---|
| S | Spoofing | Identity impersonation | Strong authentication |
| T | Tampering | Data alteration | Integrity, signatures |
| R | Repudiation | Untraceable actions | Logging, audit trails |
| I | Information Disclosure | Exposure of sensitive data | Encryption, access control |
| D | Denial of Service | Unavailability | Rate limiting, circuit breakers |
| E | Elevation of Privilege | Privilege escalation | Least privilege, RBAC |
The Threat Modeling Manifesto, a reference cited by the OWASP threat modeling cheat sheet, sums up any approach in 4 questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job. The 4 steps detailed below answer these questions directly, in a timed format suited to the pace of a sprint.
When to use STRIDE: ideal for new features, architecture changes or integrations with external systems. Not for auditing code already in production: static code scanners (SAST, for Static Application Security Testing) do that better.
The 4 steps of a threat modeling session
An effective session always follows the same sequence, whether it lasts 30 minutes or half a day. The timing below corresponds to a medium-sized feature in refinement; it scales up for a complete architecture change.
-
Describe the system: list the assets to protect, then build a simple Data Flow Diagram (DFD) with components, data flows and trust boundaries. 10 minutes.
-
Identify the STRIDE threats: for each flow and each component, ask the question: which STRIDE categories apply here? 20 minutes.
-
Assess and prioritise: for each threat identified, estimate the likelihood and the impact on a simple Critical/High/Medium/Low grid, detailed below. 10 minutes.
-
Decide on mitigations: accept, fix, transfer. Fixes become testable security requirements and user stories in the backlog. 10 minutes.
What are we protecting? Identifying the assets
An asset is anything whose compromise would cause harm: a piece of data, a secret, a capability or a trace. You list assets before looking for threats, because they are what gives each threat its weight: a threat that reaches no important asset drops to the bottom of the pile. This is the first of the four questions of the Threat Modeling Manifesto, "what are we working on?", applied to what really matters.
| Asset type | Question to ask | Example on an authentication API |
|---|---|---|
| Data | What data would a leak expose? | The user database, with password hashes |
| Secrets | Which key would give away everything else? | The private key that signs the JWT tokens |
| Capabilities | Which service must not stop? | The availability of the login endpoint |
| Traces | What will you need to prove after an incident? | The audit log of sensitive actions |
In this example, the signing key dominates: whoever holds it can forge valid tokens for any account, and every other protection falls. It therefore deserves first place in the session, even ahead of the user database.
Minimal DFD template
You do not need a dedicated tool to get started. A whiteboard or a Miro board is more than enough for the first session. What matters is clearly showing the elements that cross a trust boundary, not producing a good-looking diagram.
A useful DFD shows:
- The actors (user, external service, admin)
- The components (application, database, cache, queue)
- The data flows (HTTP requests, SQL calls, messages)
- The trust boundaries, lines that mark the border between zones of different trust levels
[User] --HTTPS--> [API Gateway] --internal call--> [Auth Service] | | trust boundary [Database] | [Profile Service] --> [Database]A trust boundary runs wherever the level of trust changes: between the Internet and the API gateway, between a service and its database, between the CI pipeline and production. Every flow that crosses a trust boundary is a candidate for a STRIDE analysis. An internal flow between two components that trust each other deserves less attention than a flow that crosses the border between the user and your system.
Worked example: authentication API
Let us take a classic authentication API with JWT (JSON Web Token, a signed token that carries the user's identity). The following example covers all 6 STRIDE categories on this same system, to show that no category should be skipped out of habit.
Threat: An attacker impersonates a user by replaying an expired or stolen JWT token.
Questions to ask:
- Do tokens have a short expiration (15 min)?
- Are refresh tokens revocable?
- Is there a check of the client fingerprint (IP, user-agent)?
Mitigation:
- JWT with a short expiration and a refresh token stored in an
HttpOnlycookie - Token revocation through an in-memory blocklist
- Backlog story: "As the system, I must invalidate all of a user's active tokens on request or when an anomaly is detected"
Threat: An attacker modifies the JWT payload to grant themselves extra roles.
Questions to ask:
- Is the signing algorithm robust (RS256 or ES256)?
- Does the API reject tokens with
alg: none? - Is the signing key properly protected?
Mitigation:
- Enforce RS256, reject any other algorithm
- Secret managed in a secrets manager with automatic rotation
- Integration test: check that
alg: noneis rejected
Threat: A user denies having changed their email address or started a sensitive action, for lack of reliable traceability of the calls made through the API.
Questions to ask:
- Is every sensitive action (password change, account deletion) logged with a timestamp?
- Are audit logs protected against after-the-fact alteration?
- Is the author of the action reliably tied to the token used at the time of the action?
Mitigation:
- Write-only audit trail for sensitive actions, with timestamp and session identifier
- Chained hashing of log entries to detect any alteration
- Backlog story: "As a user, I must be able to view the history of the actions performed on my account"
Threat: Error messages expose the username in the logs: "Incorrect password for user@company.com".
Questions to ask:
- Are error responses generic on the client side?
- Do production logs contain personal data or credentials?
- Do tokens appear in URLs (and therefore in proxy logs)?
Mitigation:
- A single response: "Invalid credentials" without saying which one
- Lint rule in the pipeline: forbid the patterns
password=,token=,secret=in logs - Backlog story: "As a developer, I must use a logger wrapper that masks sensitive fields"
Threat: An attacker floods the login endpoint with credential stuffing attempts (automated tries of stolen credentials), making the service unavailable for legitimate users.
Questions to ask:
- Is there rate limiting per IP and per account on the authentication endpoints?
- Does a circuit breaker (a mechanism that automatically cuts calls to a service that is saturating, to keep the failure from spreading) protect the database during a surge of requests?
- Do failed attempts trigger a temporary lockout?
Mitigation:
- Rate limiting per IP and per account identifier, with progressive backoff
- Credential stuffing detection through an IP reputation service
- Backlog story: "As the system, I must temporarily lock an account after several failed login attempts in quick succession"
Threat: A standard user reaches admin endpoints by tampering with the URL or the parameters.
Questions to ask:
- Are roles checked on the server side (not only on the client side)?
- Are resource IDs verifiable on the server side (no BOLA, Broken Object Level Authorisation, the flaw that lets you access another user's data by simply changing an identifier in the URL)?
- Does the API have a documented permission model?
Mitigation:
- Authorisation checked on every endpoint, not only at login
- Non-sequential UUIDs for exposed IDs
- Systematic authorisation tests in the integration tests
Prioritising: which threats should you handle first?
A session often produces around fifteen threats, and the team cannot handle them all in the sprint. You rank them by crossing likelihood and impact on the asset affected, with the same logic as the lesson Threat, risk, vulnerability. A four-level grid is enough, as long as each level is tied to a decision and a deadline rather than a mere score.
| Level | When | Decision |
|---|---|---|
| Critical | Strong impact on a major asset, plausible exploitation | Mitigation before going to production |
| High | Strong impact but hard exploitation, or the reverse | Security story in the next sprint |
| Medium | Limited impact, plausible exploitation | Security backlog, reviewed at the next refinement |
| Low | Limited impact and unlikely exploitation | Risk explicitly accepted, noted in the ticket |
The DREAD grid (Damage, Reproducibility, Exploitability, Affected users, Discoverability) scores each threat on five criteria. It is still widespread, but Microsoft, which created it, dropped it as early as 2008: two assessors would give very different scores to the same threat. A short grid, discussed as a team and tied to a decision, produces a more stable ranking than a score with five decimal places.
Writing abuse cases
An abuse case is a user story written from the attacker's point of view: "as an attacker, I want… so that…". It turns an abstract STRIDE threat into a concrete scenario the whole team understands, and it can be tested. Where the user story describes what the system must allow, the abuse case describes what it must prevent.
| STRIDE threat | Abuse case | What the test checks |
|---|---|---|
| Spoofing | As an attacker, I want to replay a stolen token after my victim has logged out, so that I can access their account | A revoked token is refused |
| Tampering | As an attacker, I want to send a token signed with alg: none, so that I can grant myself the admin role | The request is rejected with a 401 error |
| Elevation of Privilege | As a standard user, I want to change the identifier in the URL, so that I can read another customer's profile | The request is rejected with a 403 error |
Each abuse case you keep becomes an integration test that must fail on the attacker's side: that is what stops a regression from reopening the flaw six months later, when nobody remembers the session anymore.
From threats to security requirements
A mitigation decided during the session remains an intention until it is written as a requirement: a verifiable sentence, with an acceptance criterion. "Secure the tokens" cannot be tested; "a token expires after 15 minutes and a revoked token is refused" can. That is the form that goes into the Definition of Done and into the pipeline.
The diagram below follows a single threat end to end, the tampered token from the Tampering category: it becomes an abuse case, then a testable requirement, then an integration test run on every build.
| Threat | Security requirement | Verification |
|---|---|---|
| Replayed token (S) | Access tokens expire in 15 minutes; revocation takes effect immediately | Integration test on a revoked token |
| Tampered token (T) | Only the RS256 algorithm is accepted; any other algorithm is refused | Test that sends alg: none |
| Leak in the logs (I) | No password, token or secret appears in the logs | Secret scanner and lint rule in CI |
| Login flooding (D) | Beyond 5 failures in one minute, the account is temporarily locked | Load test on the endpoint |
To avoid reinventing every requirement, the OWASP ASVS (Application Security Verification Standard), whose version 5.0 was released on 30 May 2025, provides a catalogue of verifiable requirements classified by level. You pick the ones that cover the threats you kept, rather than applying everything at once.
Bringing threat modeling into the agile flow
Threat modeling does not need to be a heavy process to produce value. The point is to repeat it often, in a small format, rather than organising a big annual exercise that is quickly forgotten.
During refinement (recommended)
When refining a user story that introduces a new data flow or a new integration, add 10 to 15 minutes of threat modeling:
- Draw the DFD of the affected flow on the board
- Go through the 6 STRIDE letters, 2 minutes each
- Note the threats identified
- Create the associated security stories in the same sprint or in the security backlog
In the Definition of Done
Add a criterion to your Definition of Done (DoD, the set of conditions a story must meet to be considered done) for features that touch sensitive data or access rights:
- [ ] STRIDE threat modeling performed and documented in the ticket- [ ] Critical threats mitigated or explicitly accepted- [ ] Security stories created for the non-urgent mitigationsDuring architecture design
For architecture changes (new integration, new service), organise a dedicated 90-minute session: 20 minutes to build the DFD together, 40 minutes to go through STRIDE (5 minutes per category, 2 rounds), 20 minutes to prioritise and decide, and 10 minutes to document in the ADR (Architecture Decision Record, a short document that records an architecture decision and its context).
Common mistakes to avoid
AI-assisted threat modeling: an accelerator, not a replacement
Since 2023, tools assisted by generative AI have sped up the first step of threat modeling: generating a list of STRIDE threats from an architecture description. STRIDE GPT, an open source project built on language models, turns a text description or a GitHub repository into a first draft of threats, risk scores and tests to write within minutes, in usable formats such as Markdown or SARIF (Static Analysis Results Interchange Format, a standardised JSON format for exchanging analysis results between security tools). Commercial vendors such as IriusRisk or ThreatModeler have added comparable features to their threat catalogues.
These tools do not replace the collaborative session. A language model that receives a vague description produces generic threats, unrelated to the system's real trust boundaries, and can miss a critical flow the team knows by heart. The practice settling in during 2026 is to use AI as a draft generator and a completeness checker (have we really covered the 6 categories on each sensitive flow), then to let the team decide on prioritisation and mitigations. The TaaC-AI project, listed in the OWASP threat modeling cheat sheet, follows the same logic of threat modeling as code enriched by a language model.
Academic extensions such as STRIDE-AI adapt the grid to generative AI systems and autonomous agents, with threat categories specific to these systems (model poisoning, prompt injection). These extensions remain experimental and do not concern most teams that apply STRIDE to conventional APIs.
When should you move from a whiteboard to a dedicated tool?
The DFD on the board and coloured sticky notes (one per STRIDE category) are enough for the first sessions, those where the team is still learning the method. What matters at that stage is the conversation the exercise generates, not the final rendering: an imperfect but discussed diagram is worth more than a polished diagram produced alone in a corner.
Moving to a dedicated tool becomes relevant when two signals appear together: the team already masters the 4 steps without rereading them, and the number of sessions grows (several per sprint, on systems that share components). Open source tools such as OWASP Threat Dragon then let you keep a history of DFDs and threats from one session to the next, and AI-assisted tools (see above) can generate a first draft of threats from that DFD, without sparing the team the final discussion.
From threat modeling to the CI/CD pipeline
Threat modeling identifies design risks. Many of these risks can be translated into automated checks in the CI/CD pipeline (continuous integration and deployment), which turns a one-off decision into a permanent safeguard.
Examples of translations:
| STRIDE threat | Type of automatable check |
|---|---|
| Secrets exposed in logs (I) | Secret scanner on the code |
| Dependencies with known vulnerabilities (T/I) | Component analysis (SCA, Software Composition Analysis) |
| Missing security headers (I) | Dynamic security testing (DAST, Dynamic Application Security Testing) |
| Endpoint without authentication (S/E) | Authorisation integration tests |
| No rate limiting (D) | Load tests on sensitive endpoints |
| Process running without isolation (E) | Static configuration analysis |
Each of these checks belongs to a family of automated security testing: SAST for the code, SCA for dependencies, DAST for the running application.
Hands-on: the threat model of the common thread
This lesson ends with a mini-project, the first proof of the course: produce the threat model of the application of the common thread, or failing that of a small application you know, an API with its database and its pipeline. It is not graded automatically, but you review it against the checklist below, and it serves as a reference for all the following modules.
# Threat model: <application name>
## 1. Assets| Asset | Type | Why it matters |
## 2. Data flow diagram<DFD: actors, components, flows, trust boundaries>
## 3. STRIDE threats| Flow or component | Category | Threat | Asset affected |
## 4. Prioritisation| Threat | Likelihood | Impact | Level | Decision |
## 5. Abuse cases and requirements| Threat | Abuse case | Testable requirement | Verification |The deliverable is acceptable when every flow that crosses a trust boundary has been checked against all six categories, when every critical threat carries a decision (fix, accept, transfer), and when every fix is expressed as a testable requirement. An accepted risk carries a name and a review date, otherwise it is not accepted, it is forgotten.
Key points
- STRIDE is effective in 30 to 60 minutes. Any longer means you are trying to model everything, which is not the goal.
- The 6 categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) cover most of the threats to web and Cloud Native systems.
- The results of a threat modeling session translate into security user stories, not PDF documents.
- Start with the assets and the flows that cross trust boundaries: that is where the risks are highest.
- Every threat you keep becomes a testable security requirement, an abuse case, then an automated check; DREAD, dropped by Microsoft for its subjectivity, is not essential for prioritising.
- Threat modeling without a decision is a cost without value.
- AI-assisted tools speed up the draft of threats, but prioritisation remains a team decision.
- Translate threats into CI/CD checks to turn a one-off decision into a permanent safeguard.
Knowledge check
Check that you have the essentials of this guide. The questions cover only what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Least privilege: grant just what is needed
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
These short answers cover the questions that come up most often about STRIDE: how it differs from DREAD, how a session unfolds and where AI tools fit. Each one stands on its own.