STRIDE as a Prompt, Not a Checklist

By the end of this lesson, you will be able to...

• Use the six STRIDE prompts to question a system element or flow.

• Keep a candidate threat only when it has a system-specific path, evidence, or explicit assumption.

• Merge duplicates and record unanswered questions without pretending that a category pass proves coverage.

Idea in one sentence: STRIDE helps us ask six kinds of “what could go wrong?” questions, but the data flow and evidence decide whether an answer is a real threat, a duplicate, or an open question.

Core Insight

ShareBox has a public download endpoint. A browser sends a sharing link; the endpoint looks up the link, checks whether it is valid, then returns the associated proposal. In the previous lesson, an unintended holder of a forwarded link could read the proposal because the teaching model assumed that link possession was enough for the endpoint to accept the request.

The team now wants broader coverage. Someone suggests a familiar move: make a six-row STRIDE table for every box in the diagram and fill every cell. The resulting sheet has dozens of entries such as “spoofing possible,” “tampering possible,” and “denial of service possible.” It looks thorough, but no entry says who does what, against which flow, or why the system permits it.

The useful move is smaller. STRIDE is a mnemonic for six prompts: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Each prompt asks whether an element or flow could violate a desirable security property. It does not supply the attack path for us, and an empty or implausible prompt is allowed to stay empty.

The Small System We Will Question

Use the already scoped download path rather than inventing a new system.

partner browser or unintended link holder
        | presents shareToken
        v
public download endpoint
        | looks up current link state
        v
link record and proposal store
        | returns proposal bytes when accepted
        v
requesting browser

For this lesson, these are teaching assumptions about the path:

• The browser sends an opaque shareToken; it does not choose a document identifier.
• The endpoint obtains the associated proposal from the server-side link record.
• A valid token can be revoked or expire.
• We do not yet know whether a successful download is tied to a person in an audit record.
• We do not yet know the token’s resistance to guessing or the endpoint’s request-rate limits.

The last two rows are deliberately open. A useful model marks what it does not know instead of quietly converting missing detail into either safety or catastrophe.

The Initial Model: One Category Means One Threat

It is tempting to think that the letters are a complete threat list:

We have six categories. If we write one item in every category, the model is complete.

This works only as a reminder to look in several directions. It breaks as soon as the team tries to act on the list. “Tampering” might refer to changing a request, changing a database record, altering a log, or corrupting a response. Those are different paths with different evidence and owners. Conversely, one concrete path can fit more than one label.

The stronger model is:

system element or flow
-> STRIDE prompt
-> candidate threat statement
-> evidence or assumption
-> plausible path and objective
-> keep, merge, reject, or investigate

STRIDE creates questions. The model of the system, like the flow above, earns the answers.

The Six Prompts in Plain English

The usual names are useful after their plain meaning is clear.

These are prompts, not proof that a particular system has all six failures. The mapping is a teaching model for organizing inquiry; a real path may affect several properties. For example, a forged identity can lead to disclosure, but the team should still name the actual request and outcome rather than rely on the label.

A STRIDE Pass Over the Download Endpoint

Choose one element: the public download endpoint. Ask each question against the facts we have, then write a candidate that another reviewer could inspect.

The table contains three different results: a retained threat, rejected candidates, and questions that need evidence. That is success. A checklist that forces every cell into “threat found” produces noise, while a prompt that exposes missing information tells the team what to inspect next.

A Worked Trace: From Category to Useful Candidate

Let’s follow the information-disclosure prompt all the way through. This is the same small ShareBox scenario, not a claim about an observed incident.

The resulting candidate is not “Information disclosure: yes.” It is:

An unintended holder of a valid forwarded link can request the associated proposal from the public download endpoint if possession of that link is accepted as sufficient authorization, violating confidentiality.

This wording preserves what is known, what is assumed, and what would defeat the candidate. Requiring a verified partner identity at step 5 would break the path. An audit record after a successful response would provide evidence, but it would not prevent the disclosure. STRIDE helped us notice the question; the path tells us what a later requirement or control must change.

Merge Categories Around the Same Path

Now consider the spoofing row. A team might write:

Spoofing: an attacker impersonates the partner with a stolen link.

That can be useful if the system represents token possession as the partner’s identity. In our small model, however, the endpoint merely accepts a capability-like token. The concrete consequence is the same unauthorized read already captured under information disclosure. Keeping both rows as separate high-priority threats would count one path twice.

Record the connection instead:

This is the difference between category coverage and reasoning coverage. Categories may overlap. The path, objective, evidence, and affected boundary determine whether two entries describe the same work.

Use Missing Evidence Productively

The denial-of-service prompt raises a question: how expensive is link validation, and can one client send enough requests to interfere with legitimate downloads? We do not have a measurement or design detail. A weak threat model fills the gap with “DDoS vulnerability.” A weak reassurance says “the token is random, so it is fine.” Neither follows from the diagram.

Write an evidence request instead:

Open question: What is the request cost and rate limit for invalid and valid
shareToken checks at the public download endpoint?

Evidence needed: endpoint behavior under a bounded load test, configured limits,
and the dependency path used to validate a token.

This does not defer the reasoning. It records the exact uncertainty that prevents a conclusion. A later operational or design decision can use the answer. Until then, do not rank an imagined outage as if it were measured risk.

Trade-offs and Limits

STRIDE improves recall. A team that normally thinks only about confidential data may remember to ask about integrity, availability, and evidence. The trade-off is that a full pass can create a large number of weak candidates, consume review time, and create false confidence because every cell has text.

Use a broad pass when a new boundary, external entity, data flow, or privilege change enters scope. Use a narrower pass when the system model already rules out a candidate—for example, when the client never chooses the object identifier. In both cases, record the reason for a rejection or merge. Otherwise a later reviewer cannot tell whether a category was considered or merely forgotten.

STRIDE also does not replace other ways of seeing the system. It will not automatically reveal every business-rule abuse, privacy harm, or unsafe product incentive. A tenant-isolation requirement, a safety objective, or a domain-specific misuse case may need its own prompt. That boundary is not a defect in STRIDE; it is a reason to keep the security objective and scenario visible beside the mnemonic.

Common Confusions

Confusion: “A completed STRIDE matrix proves there are no missed threats.”

Why it is tempting: six categories feel exhaustive.

Better model: a matrix records questions asked. It cannot prove that the diagram is complete, the assumptions are true, or the team imagined every context-specific abuse path.

Confusion: “Every prompt must produce one threat.”

Why it is tempting: blank cells look unfinished.

Better model: a prompt can produce a justified rejection or an evidence request. Forcing a threat where the flow supplies no path makes later prioritization worse.

Confusion: “The category is the threat statement.”

Why it is tempting: labels are fast to write.

Better model: the category points to a kind of property failure. The threat statement still needs an actor, system behavior, preconditions, and outcome.

Confusion: “Similar labels mean separate risks.”

Why it is tempting: a disclosure path may also involve a question about identity.

Better model: merge candidates when they describe the same objective failure through the same path, and preserve the category notes as useful review context.

Trace It Yourself

Check: A reviewer proposes, “Tampering: an unintended ShareBox link holder changes the document ID in the request to read another proposal.” The diagram shows that the browser sends only shareToken and the server looks up the document. What should the team record?

Think first, then reveal.

Answer: Reject that specific candidate for the current flow and record why: the client does not control a document identifier. Do not conclude that integrity issues are impossible everywhere; revisit the prompt if a new parameter, service, or data flow appears.

Check: The team cannot tell whether downloads are linked to an identity in the audit trail. Is “repudiation” now a confirmed threat?

Think first, then reveal.

Answer: Not yet. Record an investigation question and the evidence needed. The absence of information in the model is not evidence that the product lacks the control.

Practice: Run a Small STRIDE Pass

A payroll portal allows an employee to download a monthly pay statement from a web page. The browser sends a statement link to an endpoint. The diagram says the endpoint maps the link to one statement, but it does not say whether the link is bound to a signed-in employee, whether downloads are logged, or whether repeated invalid requests are limited.

Choose three STRIDE prompts. For each, write a candidate, rejection, or open question. Then merge any candidates that describe the same path and name the evidence that would change one of your decisions.

A good answer should:

• use the shown link-to-statement flow instead of assuming access to the payroll database;
• identify disclosure as a candidate only when the authorization condition supports it;
• treat unknown logging and request limits as questions requiring evidence;
• reject a client-controlled-statement-id path if the diagram truly omits that input; and
• avoid counting one unauthorized-read path once as spoofing and again as disclosure without explaining the distinction.

Connections

• Lesson 006 turns a retained candidate into an abuse case and a causal attack path.
• Lesson 008 asks multiple reviewers to challenge the completeness and assumptions behind this discovery work.
• Lesson 009 converts retained threats into testable security requirements.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare the six STRIDE prompts with their associated security properties and use them in the context of a modeled system.
• [PROJECT] OWASP Threat Modeling Project — Focus: Keep the work tied to the practical questions of system scope, threats, responses, and review.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Use its principles to treat threat modeling as collaborative, context-aware reasoning rather than a compliance exercise.

Key Takeaways

• STRIDE is a set of prompts for discovery, not a list of threats that applies unchanged to every element.
• A useful candidate connects a prompt to an element or flow, evidence or an assumption, an actor, and an objective failure.
• Keep, merge, reject, or investigate candidates based on the path; do not force every category to contain a threat.
• A completed matrix is not proof of coverage. The system model, objectives, and remaining open questions still matter.