TL;DR: Answer four questions: what are we building, what can go wrong, what will we do about it, did we do it well. Draw a data-flow diagram with external entities, processes, stores, flows and trust boundaries; walk the boundary-crossing flows and each element through STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege); and produce a short list of specific threats, each with a decision, an owner and a test. Do it at design time and again whenever a trust boundary changes.
How to approach it
Show the process rather than define it. Pick a small system the interviewer will recognise, such as a file-sharing service, and narrate the four questions as you go. Ask one clarifying question about scope ("the upload path, or the whole product?") so the walk-through stays deep rather than wide.
A strong answer
What are we building?
DFD, trust boundaries
What can go wrong?
STRIDE per element
What will we do?
mitigations, owners
Did we do it well?
review, tests
STRIDE
One threat class per letter
1. What are we building? Draw the data-flow diagram. External entities (users, partner APIs, the email provider), processes (the upload API, a thumbnail worker), data stores (the file store, the metadata database) and data flows between them. Then draw trust boundaries: internet to service, service to third party, and any internal line where components are trusted differently, such as the worker that parses untrusted files.
2. What can go wrong? Walk STRIDE, starting with flows that cross boundaries. For the upload flow:
| Threat | Concrete version | Mitigation |
|---|---|---|
| Spoofing | Uploading as another user with a stolen or forged session | Authenticated sessions, short-lived tokens |
| Tampering | Changing a file's owner field in the request | Owner set server-side from the session, never from input |
| Repudiation | A user denies uploading illegal content | Audit log tying upload, account and source |
| Information disclosure | Fetching /files/{id} for someone else's file | Ownership check on every read |
| Denial of service | Uploading huge or many files | Size limits, per-user quotas |
| Elevation of privilege | A crafted image exploits the thumbnail parser | Parser runs in a sandbox with no credentials or network |
STRIDE-per-element keeps it fast: external entities are mainly spoofed, stores are tampered with, disclosed and exhausted, and processes get all six.
3. What are we going to do about it? Every threat gets a decision: mitigate, accept with an owner and a reason, transfer, or remove the feature. Mitigations are specific enough to test: "a request for another user's file returns 403" can become an automated test; "use access control" cannot.
4. Did we do a good job? Check that the diagram matches what was built, that mitigations shipped, and that the tests exist. Reopen the model when a boundary changes, such as adding a model provider or a new integration.
When. At design review, while changes are cheap; before introducing a new trust boundary; and on significant changes. A one-page model kept current is worth more than a long document written once.
What interviewers probe next
- "How do you threat-model something you did not design?" Interview its owners, trace one real request, and draw the diagram from what is deployed rather than from the design document.
- "How do you prioritise thirty findings?" By impact on the asset and how reachable the entry point is; fix cheap high-impact items first and accept low ones explicitly.
- "Now the service summarises uploads with an LLM. What changes?" The file content becomes a writer into the model's context, so every action the summariser can take becomes reachable by whoever uploads a file.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Your team is building a file-sharing feature: users upload documents, share links, and recipients download them.
Start here
What four questions structure threat modelling?
What is the output of each question?
What are we building, what can go wrong, what will we do about it, and did we do it well. They keep the exercise tied to decisions.
Carry it forwardFour questions drive threat modelling.
Weak answerProducing a diagram without decisions.
Constraint changes
What does the diagram need?
Where are the trust boundaries?
External entities, processes, data stores, data flows and trust boundaries: uploader, recipient, upload service, storage, link service and download service.
Carry it forwardData-flow diagrams with boundaries.
Weak answerArchitecture boxes without flows.
Constraint changes
How does STRIDE apply to share links?
Which STRIDE threats fit a link?
Spoofing: guessable links; tampering: changing link permissions; repudiation: no log of who shared; information disclosure: links forwarded or indexed; denial of service: huge uploads; elevation: link holders gaining edit rights.
Carry it forwardWalk STRIDE per element and flow.
Weak answerApplying STRIDE only to the server.
Constraint changes
What would you do about link disclosure?
What if a link is forwarded?
Unguessable tokens, optional expiry and passwords, restriction to named recipients for sensitive files, revocation, and logs of access. Choose defaults based on sensitivity.
Carry it forwardExpiry, revocation and named recipients.
Weak answerPermanent public links by default.
Constraint changes
How do you check you did it well?
Which threats have no control?
Track each threat to a control, test, or accepted risk with an owner, and revisit the model whenever the design or its data flows change.
Carry it forwardEvery threat ends in a decision.
Weak answerThreat models that never update.
Now defend it
What would the threat model produce?
A data-flow diagram with trust boundaries; STRIDE threats per element and flow, such as guessable or forwarded links, permission tampering, missing audit logs, oversized uploads and malicious files; controls like unguessable expiring revocable links, named recipients, access logs, size limits and file scanning; and owners for each decision, revisited on change.
How it's scored
Weak: Recites STRIDE's letters without a diagram, or lists generic controls such as "encryption and access control" for every row.
Hire: Draws the diagram, marks trust boundaries, walks one flow through STRIDE with concrete threats and mitigations.
Strong Hire: Produces decisions with owners and tests, explains when to redo the model, and adapts it when the interviewer adds a component.
Common mistakes
- Skipping trust boundaries, so every box gets the same scrutiny.
- Listing threats with no decision attached.
- Treating the threat model as a one-time document.
- Confusing a vulnerability scan with a threat model.