Tools / STRIDE Threat Model Worksheet
STRIDE Threat Model Worksheet
List the entities, processes, data stores, and data flows in a design, flag their trust properties, and get a STRIDE checklist per component — the Spoofing/Tampering/Repudiation/Info-disclosure/DoS/Elevation categories that actually apply to each element type. Runs entirely in your browser.
Browser client — External entity
- S · Spoofing
Not marked authenticated — anything on the other side of this element could be impersonated. Verify identity before trusting input from it.
- R · Repudiation
Not marked logged — an action here could be denied later with no audit trail to disprove it.
API gateway — Process
- S · Spoofing
Authenticated — confirm the mechanism resists credential theft and replay, not just presence of a check.
- T · Tampering
Encrypted — confirm integrity is checked too (encryption alone doesn't prevent tampering without a MAC/signature).
- R · Repudiation
Logged — confirm logs are tamper-evident and capture enough to attribute an action to an actor.
- I · Information disclosure
Encrypted — confirm access to the decrypted form is itself scoped to who actually needs it.
- D · Denial of service
Exposed across a trust boundary — needs rate limiting, quotas, or backpressure so it can't be exhausted by an untrusted caller.
- E · Elevation of privilege
Not marked privileged — confirm it truly can't escalate (e.g. via a misconfigured service account or inherited role).
Order database — Data store
- T · Tampering
Not marked encrypted — consider whether data at rest or in transit here needs integrity protection.
- I · Information disclosure
Not marked encrypted — anyone with read access to this element sees the data in the clear.
- D · Denial of service
Internal-only — lower DoS exposure, but confirm it can't be exhausted by a compromised internal caller.
Client → gateway request — Data flow
- T · Tampering
Encrypted — confirm integrity is checked too (encryption alone doesn't prevent tampering without a MAC/signature).
- I · Information disclosure
Encrypted — confirm access to the decrypted form is itself scoped to who actually needs it.
- D · Denial of service
Exposed across a trust boundary — needs rate limiting, quotas, or backpressure so it can't be exhausted by an untrusted caller.
// About this tool
STRIDE Threat Model Worksheet
STRIDE is Microsoft's mnemonic for six threat categories — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Not every category applies to every kind of design element: an external entity can be spoofed but can't really be "denied service" in the usual sense, while a data flow can be tampered with or disclosed but isn't really "spoofed." This tool applies the standard STRIDE-per-element mapping so each component only gets the categories that actually make sense for it.
For each component you describe — its type (external entity, process, data store, or data flow) and a handful of trust properties (crosses a trust boundary, authenticated, encrypted, logged, privileged) — the tool generates the applicable STRIDE questions and flags the ones a missing property makes concrete: an unauthenticated component gets a spoofing warning, an unlogged one gets a repudiation warning, and so on.
This produces a starting checklist for a design review, not an automated risk score — the point is to make sure nobody skips asking "can this be spoofed / tampered with / repudiated" for a component just because it wasn't top of mind. Nothing you enter is sent anywhere; the whole model lives in your browser tab.
// When to use it
Review a new service's design
Model each API, database, and queue as a component, mark what's authenticated and encrypted, and work through the warnings before the design is finalized.
Prep for a design review meeting
Build the model ahead of time so the review focuses on the flagged gaps instead of re-deriving which STRIDE categories even apply.
Onboard someone to threat modeling
The per-type STRIDE mapping and the reasoning behind each finding double as a worked example of how STRIDE-per-element analysis is supposed to work.
// Questions
Does this replace a full threat modeling exercise?
No. It's a structured starting checklist, not a substitute for a design review with people who know the system. Attacker capability, business impact, and mitigations still need human judgment.
Why do only some threat categories show up for some components?
This follows Microsoft's classic STRIDE-per-element mapping: external entities are only really subject to spoofing and repudiation, data stores and data flows aren't meaningfully "spoofed," and elevation of privilege only applies to processes. Showing every category for every element buries the ones that matter.
Is my system design uploaded anywhere?
No. Everything you enter stays in your browser tab — there's no save, no account, and no server round-trip.
// Related tools