Threat Modeling with STRIDE: A Step-by-Step Guide for Teams
Advanced4 minInnovialabs editorial team
In short
Threat modeling with STRIDE means sketching how data moves through your system, marking where trust changes, asking six standard questions about each element and turning the real risks into prioritized backlog tasks before code is written.
What threat modeling with STRIDE is
Threat modeling is a structured conversation about what can go wrong in a system and what you will do about it. It works best during design, when fixing a flaw means changing a diagram, not rewriting a service.
STRIDE is a checklist of six threat categories created at Microsoft:
| Letter | Threat | Property it breaks | Example |
|---|---|---|---|
| S | Spoofing | Authentication | Logging in with a stolen token |
| T | Tampering | Integrity | Changing a price in a request |
| R | Repudiation | Non-repudiation | A user denies an action, and no log proves it |
| I | Information disclosure | Confidentiality | An API returns other users' data |
| D | Denial of service | Availability | A heavy endpoint brings the database down |
| E | Elevation of privilege | Authorization | A regular user calls an admin method |
A whole session follows four simple questions: What are we building? What can go wrong? What will we do about it? Did we do a good job?
Step 1. Draw a data flow diagram
A data flow diagram (DFD) needs only five element types:
- External entity — a user, partner system or payment provider you do not control.
- Process — your code: API, worker, frontend.
- Data store — database, cache, file storage, queue.
- Data flow — an arrow showing what data moves and how (HTTPS, gRPC, webhook).
- Trust boundary — a dashed line where the level of trust changes.
Keep it to one feature or service. A one-screen diagram gets discussed; a wall-sized one gets ignored. Tools like OWASP Threat Dragon help, but a whiteboard works just as well.
Step 2. Mark trust boundaries
Boundaries are where most threats live. Typical ones:
- the internet and your backend;
- the backend and a third-party API;
- a public service and an internal admin panel;
- your application and the database;
- tenants in a multi-tenant system.
Every arrow crossing a boundary is a question: who is sending this, can it be forged, and what happens if it is malicious?
Step 3. Apply STRIDE to each element
Go element by element. Not every category applies everywhere; a common mapping:
| Element | Relevant categories |
|---|---|
| External entity | S, R |
| Process | S, T, R, I, D, E |
| Data store | T, I, D (and R if it holds logs) |
| Data flow | T, I, D |
Write each threat as a concrete sentence: "An attacker replays a captured webhook to mark an unpaid order as paid." Vague entries like "hacking" cannot be fixed or tested.
Session tips:
- Invite a developer, a QA engineer, a product person and whoever runs the infrastructure.
- Timebox to 60–90 minutes per feature.
- One person facilitates and asks STRIDE questions; another records.
- Do not argue about fixes during discovery. Collect first, decide later.
Step 4. Prioritize
You will find more threats than you can address. A simple scale works better than precise formulas:
- Impact: what is lost — money, personal data, availability, reputation.
- Likelihood: how easy the attack is, whether it needs insider access, whether public tools exist.
Combine them into high / medium / low. For each threat, choose a response: mitigate (add a control), eliminate (remove the feature or data), transfer (use a provider that handles it) or accept (document the decision and who made it).
Step 5. Turn threats into backlog tasks
A threat model that stays in a document changes nothing. Each mitigated threat becomes a ticket with testable acceptance criteria:
Task: Verify webhook signatures from the payment provider. Threat: Tampering/Spoofing on the provider → backend flow. Done when: requests without a valid signature are rejected; requests older than the allowed window are rejected; a test covers both cases.
Link tickets back to the model, add security checks to the definition of done, and revisit the diagram when the architecture changes — a new integration, a new data store or a new user role.
Common mistakes
- Modeling the entire company at once. Start with one feature that handles money, personal data or permissions.
- Doing it after release. Then it turns into a pentest report nobody has time for.
- Listing only technical threats. Repudiation and abuse of business logic, such as unlimited promo codes, matter just as much.
- No owner. Every accepted risk needs a name and a date for review.