Threat Modeling Interview Exercise: Draw Boundaries Before Listing Attacks

A threat modeling interview exercise becomes useful when you can point to a boundary and explain which assumption stops being safe there. Start with the system, its assets, and who may act on them. Then describe a credible failure, select a control, and specify a test. Listing SQL injection, phishing, and denial of service before establishing the design leaves the interviewer guessing what you are actually protecting.

This walkthrough uses an original multi-tenant file-sharing service. The goal is a small, defensible model you can revise during a discussion. For a related authorization drill, practice Design an access control system (RBAC + resource-based) on PracHub, then explain how its permission decisions apply to downloads and background jobs.

Start with a product contract

Official guidance: OWASP organizes threat modeling around understanding the system, identifying failures, choosing responses, and evaluating the result. Its guidance treats assumptions and validation as part of the model. It does not prescribe a universal interview scorecard. OWASP threat modeling overview

Candidate-report boundary: the linked PracHub questions are reported practice records. They establish useful exercises, not proof that a particular employer asks this file-sharing scenario. Editorial inference: the sequence and design below are an original preparation method for making security reasoning visible.

Suppose organizations upload documents, generate previews, and share files with colleagues. A recipient must belong to the same organization and have permission for the file. Owners may revoke access. Uploaded bytes stay unavailable until scanning completes. Support staff can inspect operational metadata but cannot read document content by default.

Confirm what is excluded: anonymous public links, cross-organization sharing, and collaborative editing are outside the initial exercise. Write those exclusions down. If the interviewer later adds public links, that is a meaningful change to the authorization model, not an excuse to quietly ignore an earlier assumption.

Ask what “revoke” means. Does the promise cover future requests only? Must an already-issued download URL stop working? Can a recipient retain a file already downloaded? The last action cannot generally be undone by changing server permissions. Distinguishing these outcomes prevents an impossible security promise.

Draw flows that carry both data and authority

Use five components: browser, application API, metadata database, private object storage, and a scan/preview worker. Add a queue between the API and worker. Draw a separate support console because its users and permissions differ from ordinary customers.

A compact text model is sufficient before adding visual detail:

Browser --session + operation--> API --scoped query--> Metadata
                                |
                                +--upload bytes--> Quarantine storage
                                |
                                +--job reference--> Queue --> Worker
                                                       |
                                      scan result + version
                                                       v
                                             Metadata / Preview storage

Browser --authorized download request--> API --> Private object storage
Support console --support identity--> Metadata-only support endpoint

Arrows describe specific interactions. “API talks to storage” hides the important question: which principal signs the storage request, and what object is that principal permitted to access? Annotate an upload with file identity, tenant identity, object version, and the identity responsible for the operation.

The network edge is one boundary, but it is not the only one. Two tenants sharing the same database still require logical isolation. An asynchronous worker has different authority from the browser that triggered a job. A support account authenticated by the same identity provider may have a separate administrative role and approval process.

Official guidance: OWASP's threat-modeling cheat sheet describes system modeling and trust boundaries as inputs to threat identification. Apply the idea to changes in control and assumptions, rather than drawing a box around every machine. Threat Modeling Cheat Sheet

Write the permission matrix before proposing controls

For this exercise, assume the API resolves tenant membership from validated server-side identity context. A request parameter can select a resource, but it cannot grant membership. The file record binds its object key and version to a tenant; a caller-provided object key is not that binding.

This matrix is a proposed contract, not a universal file-sharing policy. A tenant administrator might need more authority in another product. If so, add that role explicitly and discuss accountability rather than assuming “administrator” means unlimited access everywhere.

Official guidance: OWASP recommends least privilege, denial by default, permission checks on every request, and tests for authorization logic. That supports checking the object and requested action at the enforcement point, even when a previous screen already checked membership. Authorization Cheat Sheet

Turn a boundary crossing into a threat statement

Use a complete sentence: “An authenticated user from tenant B requests tenant A's file identifier; if the download API loads the object without checking tenant and grant, it returns confidential bytes across the tenant boundary.” The statement names the actor, entry point, missing check, asset, and consequence.

Contrast that with “broken access control.” The category is correct but insufficient to review. It does not identify whether the vulnerable path is download, preview, search, export, or a support tool. Every alternate route to the same bytes belongs in the model.

STRIDE can help you ask additional questions after this concrete path exists. Spoofing asks whether the job's claimed identity can be forged. Tampering asks whether a queued object version can be changed. Repudiation asks whether grant changes have attributable evidence. Information disclosure asks where bytes escape. Denial of service asks whether expensive preview jobs exhaust capacity. Elevation of privilege asks whether the worker can exercise authority beyond its job. Microsoft STRIDE reference

Do not force one finding into every category. Several labels can describe one scenario, and an empty category does not prove coverage. Use the categories as prompts, then consolidate findings by the failure and control that matter.

Prioritize three concrete failure paths

The following register is an original design exercise. Priority is qualitative: discuss exposure, prerequisites, impact, and uncertainty instead of inventing precise probabilities.

In this product, cross-tenant disclosure deserves early attention because ordinary authenticated users can reach the download endpoint and the impact is direct. A preview parser compromise may also be severe, but its priority depends on supported formats, sandboxing, network access, and workload credentials. Explain which unknown would change your ranking.

For availability, measure the expensive operation. Upload byte limits alone may not bound parsing cost. A small compressed file can expand significantly; a queue can fill faster than workers finish. Consider decompression limits, execution deadlines, memory limits, tenant quotas, and workload isolation. OWASP's upload guidance discusses layered validation and limits; no single extension check establishes safety. File Upload Cheat Sheet

Follow one file through an asynchronous race

A file is uploaded as version V1. The API queues a scan. Before the worker returns, the owner replaces the file with V2. The worker reports that V1 passed. A weak implementation stores only file.clean = true, allowing V2 to inherit a result produced for different bytes.

The security invariant should be version-specific: a downloadable object version must have its own accepted scan result. Store the object version or immutable digest with the job and result. Update clearance conditionally, and ensure downloads retrieve precisely the cleared version. If storage keys are mutable, naming a key alone is not enough.

Now add retries. A worker may deliver the same result twice or return an older result after a newer job. Results should be idempotent for their job/version and should not regress current state. Make failure explicit: pending, rejected, processing failed, and cleared are different outcomes. A timeout must not accidentally become clearance.

This is why a data-flow diagram needs state transitions. Drawing a “scanner” box establishes only that a component exists. It does not prove that its answer authorizes the bytes eventually served.

Challenge the design with revocation

Suppose the interviewer changes the requirement: a revoked recipient must lose access to future downloads immediately. Your API checks the grant, then returns a storage URL valid for ten minutes. The recipient can continue using that capability after the grant changes unless the delivery path supports an additional check or invalidation mechanism.

State the tradeoff directly. A short-lived URL reduces the exposure window but does not satisfy immediate revocation by itself. An application-mediated download can recheck current authorization, at the cost of operational load and a dependency on the authorization service. A delivery layer with effective revocation may offer another option, but its actual semantics must be verified.

Define the timing contract for an in-flight download. Is authorization decided at request start, or must streaming stop after revocation? What happens during a permission-service outage? For confidential files, failing closed can be appropriate, but it creates an availability tradeoff that should be visible to the product owner.

Prove the model with a small negative-test set

Use synthetic tenants A and B, one owner, one recipient, and two file versions. Test both allowed behavior and denied behavior. A system that rejects everything is secure only in the narrowest, useless sense; the tests must preserve the product contract.

Exercise a tenant B read of tenant A's identifier, a revoked recipient request, a preview request without a grant, a pending scan, an old scan result arriving after replacement, and a worker job referring to an unrelated object. Verify the observable outcome: no bytes returned, no unauthorized state change, and a bounded audit record explaining the decision.

Avoid logging the confidential document or reusable download credential as evidence. Record safe identifiers, decision outcome, policy version, actor context, and a correlation reference appropriate to the system. Monitoring supports investigation; it does not replace preventive authorization.

Finally, name residual risk. An authorized recipient can copy downloaded content. An approved parser can still contain unknown defects. A privileged operator may abuse permitted access. Explain containment and ownership for these risks instead of claiming the design eliminates every attack.

Practice the reasoning through five adjacent questions

These candidate-reported PracHub records help rehearse specific parts of the exercise. They are not reproductions of this fictional interview prompt.

Close your answer by tracing one threat all the way through the model: boundary, asset, invariant, control, test, residual risk. That gives the interviewer something concrete to challenge and gives you a clear way to revise the design when requirements change.

Sources and Further Reading

• OWASP Threat Modeling overview
• OWASP Threat Modeling Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP File Upload Cheat Sheet
• Microsoft Threat Modeling Tool: STRIDE threats