In this article
Before you start
This page is one step of the cyber security interview questions learning path, and it assumes no earlier security training.
Why interviewers ask this
A scenario question hands you a system in a sentence or two and asks what could go wrong with it. The consequence of answering badly is visible within a minute: an unstructured list of attacks sounds like memory, not judgement. Interviewers use the question to see whether a candidate can turn a vague system into something checkable, and whether the candidate knows when to stop.
A weak answer lists every attack the candidate has heard of. A strong answer states what is in scope, draws the system, checks each part and each boundary crossing against a fixed set of threat types, picks a response per threat, and says how the result would be checked. Staff-level answers also rank the threats and say which risks are accepted. This is the same thinking that application security interviews test with design prompts.
Threat modelling a scenario from first principles
- Data flow diagram
- A data flow diagram (DFD) is a drawing of a system made of four element types, data flows, data stores, processes and interactors, that shows where data moves. For threat modelling a fifth item is added: the trust boundary. It is the picture every later step works from.
- Trust boundary
- A trust boundary is a line on a data flow diagram where the level of trust changes, so that you do not trust what is on the other side of it. Data that crosses the line is a candidate for attack, so crossings get the closest attention.
In plain words
Think of securing a house. First you draw the floor plan and mark which doors lead outside. Then you stand at each door and window and ask what could go wrong there. Next you decide on locks and lights. Finally you walk the house again to check the plan works.
The analogy breaks in one place. A house has a few fixed doors. Software gains new interfaces whenever it changes, so the plan must be updated and cannot be a one-off.
In one precise sentence, threat modelling in an interview is drawing the system, checking each element and boundary crossing against a fixed list of threat types, choosing a response for the threats that matter, and checking the result.
The four steps below follow four questions in order, and each question produces one output: a model, a threat list, mitigations and a review.
Step-by-step description
- Draw the system and its trust boundary.
- Walk each element and crossing.
- Pick a mitigation per ranked threat.
- Review the result and keep it current.
- Threat modelling asks four questions in order.
- Each question produces one output: a model, a threat list, mitigations and a review.
Step 1: Draw the system and its trust boundary
The first question, what are we working on, is answered with a model of the system. The Mozilla Developer Network (MDN) threat-modelling guide lists data flow diagrams, architecture diagrams or use-case diagrams showing components, data flows, trust boundaries and dependencies. In an interview, a data flow diagram is the quickest to draw.
Input: the scenario sentence. Output: a diagram with processes, data stores, interactors, data flows and trust boundaries, following Hernan et al. (2006). State scope aloud. Threats aimed at other layers become external dependencies of your model.
Two sanity rules from the same article help. Beware of magic data sources or sinks, and make sure a process always reads and writes data. You now have a diagram whose parts can each be checked, which is what the next step does.
Step 2: Walk each element and boundary crossing
Walking the diagram means checking every element and every boundary crossing against the six STRIDE threat types, rather than recalling attacks. Each type breaks one property: spoofing breaks authentication, tampering breaks integrity, repudiation breaks non-repudiation, information disclosure breaks confidentiality, denial of service breaks availability, and elevation of privilege breaks authorisation (Hernan et al., 2006, Figure 3).
Element type decides which threats apply. A process is checked for all six threat types. An interactor is checked for spoofing and repudiation. A data flow and a data store are each checked for tampering, information disclosure and denial of service in the original 2006 chart. The DevSecOps guideline adds that every crossing of a trust boundary is a candidate threat.
Input: the diagram. Output: a list of candidate threats, each tied to an element. Exposure sets effort: in the worked system of Hernan et al., a flow that crosses the boundary is clearly more exposed than one that stays inside it, and for inside flows it is a matter of priority.
Text description of the diagram
- A process is checked for all six threat types.
- An interactor is checked for spoofing and repudiation.
- A data flow and a data store are each checked for tampering, information disclosure and denial of service.
Step 3: Choose a response for each threat that matters
Choosing a response means answering the third question, what are we going to do about it, with one concrete mitigation per threat you keep. A mitigation names the control and the property it protects. "Validate the JWT on every request" answers spoofing; "limit upload size" answers denial of service.
Not every candidate threat deserves a mitigation. The community page on threat modelling says a threat becomes a significant risk when the likelihood and the impact combine, and that evaluating every combination of agent, attack, vulnerability and impact is often a waste of time and effort. So rank the threats and say which you would fix first.
Input: the candidate threats. Output: a short list of mitigations in rank order, plus the risks you accept. Say the acceptance aloud, because naming what you leave open is part of the answer. Identity and access analysts work with the controls that answer spoofing and authorisation threats.
Step 4: Validate the model and say what is left
Validation answers the fourth question, did we do a good enough job, by checking the result and committing to keep it current. The Manifesto prefers continuous refinement to a single delivery, and a culture of finding and fixing design issues over checkbox compliance.
Input: the model and its mitigations. Output: a review plan and a list of open assumptions. In an interview, say who would review the model, how a mitigation would be tested, and that the model is revisited when the design changes.
Be honest about limits. Hernan et al. write that they cannot yet show that components which are each immune to a spoofing threat are not susceptible to it when composed into a system. A finished model is therefore not proof of security. It is a record of what was considered.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
The prompt, in our own words, is: "Users upload files through a web endpoint and the files are kept in storage. Threat-model it." This follows the upload example in the DevSecOps guideline.
Step 1 gives one interactor (the user), one process (the upload endpoint), one data store (file storage) and two data flows (the request and the write), with a trust boundary between the user and the endpoint, drawn as a labelled box in the figure. The flow from the user to the upload endpoint crosses the trust boundary. The write to storage stays inside it.
Text description of the diagram
- The flow from the user to the upload endpoint crosses the trust boundary.
- Every crossing of a trust boundary is a candidate threat.
Step 2 counts the checks. The interactor gets 2, the process 6, the store 3 and each of the two flows 3, so the walk has 17 candidate threat checks.1 Every crossing of a trust boundary is a candidate threat, so the request flow comes first.
Step 3 gives one threat and one mitigation per category. Five mitigations follow the guideline; the elevation-of-privilege row follows the OWASP community page on unrestricted file upload, which describes uploads leading to code execution and overwritten files. The likelihood and impact scores below are illustrative values from 1 to 5, not measurements, and the score is their product.1
| Threat | Example mitigation | Score (illustrative) | Rank |
|---|---|---|---|
| Spoofing: forged identity in a header | Validate the JWT on every request | 12 | 1 (tie) |
| Denial of service: huge uploads | File size and rate limits | 12 | 1 (tie) |
| Elevation of privilege: an uploaded script is executed, or a crafted file name writes outside storage | Allow-list file types, store under a generated name outside the web root, run the handler with least privilege | 10 | 3 |
| Information disclosure: errors leak paths | Sanitise error messages | 9 | 4 |
| Tampering: file changed in transit | Encrypt the connection and verify the file hash | 8 | 5 |
| Repudiation: uploader denies the upload | Log the authenticated user and file hash | 4 | 6 |
Step 4 closes the example. Name one accepted risk with its reason: repudiation is accepted at its illustrative score of 4 because uploads are already logged with the user. Say who reviews the model, for example the team that owns the endpoint plus a security reviewer. Say what triggers a revisit: a new file type or a new consumer of the storage.
In the round you would say the top two aloud, mention the rest in one sentence each, and name what you accept.
Trade-offs and edge cases
No single method is the only right one. Hernan et al. write that anyone who says his method is the only right one is mistaken, and the community page says there is no right way to evaluate the search space of threats. The Manifesto adds that no single representation is ideal, so use more than one when a problem needs it. STRIDE is a good default for a time-boxed answer, not a standard.
Data stores are a known variant. The original 2006 chart gives them tampering, information disclosure and denial of service. Other STRIDE-per-element charts add repudiation for data stores, so say which table you are using.
Flows entirely inside a trust boundary are a matter of priority, not exemption. Situations change, so defence in depth can still be worth the effort (Hernan et al., 2006). Likewise, an out-of-scope data sink is not out of scope from a security view (Hernan et al., 2006).
The composition caveat from Step 4 applies too: checking parts does not prove the whole. After design, security operations centre (SOC) analysts are the people who see whether a mitigation fails in production, and threat intelligence can inform how likely an attack is.
How to answer it in an interview
How would you threat-model a service where users upload files?
I would start by asking what we are working on, so I draw the system as a data flow diagram with a trust boundary around the part we control. Then I walk each element and each boundary crossing with six threat types: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. For each real threat I name one mitigation, such as validating the token on every request or limiting upload size. I rank by likelihood and impact rather than listing everything. Finally I say how we would check the result: review the model with the team and revisit it when the design changes.
The spoken structure: say the scope, draw the diagram, walk the elements, give a mitigation per ranked threat, then close with validation.
Common mistakes
- "Let me list every attack I know." (wrong) The community page calls evaluating all combinations a waste of effort. (right) "I check each element and crossing, then rank by likelihood and impact."
- "STRIDE is the one correct method." (wrong) Hernan et al. say no method is the only right one. (right) "STRIDE is a checklist I use here; other representations can add views."
- "Inside the trust boundary needs no analysis." (wrong) It is a priority call, not an exemption. (right) "Boundary crossings first, internal flows next, because situations change."
- "The model is finished, so the system is secure." (wrong) Components analysed alone can still fail when composed. (right) "The model records what we considered, and we revisit it when the design changes."
Follow-up questions
What are the four key questions of threat modelling?
The four key questions are "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?". The Manifesto presents them as a methodology-agnostic frame, not a how-to.
What does STRIDE stand for?
STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. They map to authentication, integrity, non-repudiation, confidentiality, availability and authorisation.
How do you prioritise threats in a scenario question?
Combine likelihood and impact, rank the results and fix the top ones first. Say which risks you accept rather than pretending to cover everything.
How would you threat-model a login service?
The key boundary is between the public internet and the login endpoint, so the first threat is spoofing: an attacker trying stolen or guessed credentials at scale. Mitigate with rate limits, lockout or step-up checks and logging of failed attempts, then walk the rest of the elements as above.
How would you threat-model an internal admin panel?
The key boundary is between ordinary users and the privileged functions of the panel, so elevation of privilege is the top threat, with repudiation by insiders close behind. Mitigate with role checks on every action and an audit log that names the acting user.
How would you threat-model an incoming third-party webhook?
The key boundary is the public endpoint that receives the call, so the top threat is spoofing of the sender. Verify the sender's signature on every request, and add limits so a flood of calls cannot cause denial of service.
- Answer in four questions: scope and draw, find threats, choose responses, validate.
- Walk the diagram element by element and crossing by crossing, never from memory.
- Check a process for six threat types, an interactor for two, a flow or store for three.
- Rank threats by likelihood and impact, and say which risks you accept.
- A threat model is maintained with the system and does not prove security.
Sources
- Threat Modeling Manifesto — Threat Modeling Manifesto working group, 26 Oct 2026
- Uncover Security Design Flaws Using The STRIDE Approach — MSDN Magazine, Microsoft Learn archive (Hernan, Lambert, Ostwald, Shostack), 1 Nov 2006
- Threat Modeling — OWASP Community, 26 Oct 2026
- Threat modeling — MDN Web Docs, 26 Oct 2026
- Threat Modeling, DevSecOps Guideline — OWASP DevSecOps Guideline, 26 Oct 2026
- Unrestricted File Upload — OWASP Community, 26 Oct 2026
