Turn a feature diagram into a threat model

A threat model starts with the system people intend to build. Identify valuable assets, actors, data flows and trust boundaries. A boundary is a change in authority or trust, such as browser input entering a backend, one tenant requesting another tenant's object, or a worker using a cloud identity. Drawing boxes without those relationships does not identify the security decision.

Describe an abuse case as an actor taking an action against an asset through a specific path. 'Data breach' is an outcome, not a useful test case. 'A tenant changes an invoice ID and retrieves another tenant's file' names a path that can be checked. Keep assumptions visible, including whether the attacker has a normal account.

Choose controls where they can enforce the intended rule. Input validation can reject malformed data, but a valid-looking object ID can still be unauthorized. Encryption protects some transport or storage exposure; it does not decide whether the requester is allowed to read a decrypted object.

Prioritize by plausible impact and exposure, then state uncertainty. A threat model is not a claim that every listed attack is happening. It is a structured way to identify what must be prevented, detected or accepted. A low-confidence but high-impact path may deserve a small test before a large design change.

The final artifact should connect each important threat to a control, an owner and verification. Revisit the model when the feature's data flow or authority changes. A new export worker can create a new boundary even if the user-facing screen stays the same.

Teaching feature lets a signed-in tenant administrator export invoices to a downloadable file. The browser submits a tenant ID and date range. The API creates a job. A worker reads invoices, writes a file to object storage and returns a download link. The worker identity can read several tenants because it serves the whole product.

The main asset is invoice data. Additional assets include the worker's credentials and the integrity of the export job. Actors include a normal tenant administrator, the API, the worker and the storage service. The browser is not trusted to declare tenant authority merely because it is signed in. The queue message is also a boundary: the worker must receive a validated job identity and scope, not an arbitrary database query.

Now trace one abuse case. A tenant-red administrator submits tenant-blue as a body field. If the API trusts that field, the privileged worker may produce a blue export. A secure queue does not fix the mistake because the API itself created the unauthorized job. The control belongs at the authorization decision and must remain present in the worker's scoped read.

A second abuse case starts with a valid red export but an overbroad download link. If the file link is a bearer capability, anyone holding it may be able to use it until expiry. This may be acceptable under a stated product policy, but it should not be described as per-request user authorization unless the download path actually checks identity. Choose the link lifetime, access logging and revocation behavior from the data risk.

The negative test alone can be misleading. A system that denies every export would block the abuse but fail the feature. Pair each denial with allowed behavior. This is useful interview evidence because it shows that security preserves the intended function while excluding unauthorized paths.

The model also records residual risk. An authorized administrator can download their tenant's invoices and share them outside the product. If preventing all onward sharing is not a requirement the product can enforce, say so. Do not promise that short-lived links stop an authorized user from copying data. Security claims should match the actual control.

Finally, make the model maintainable. Attach it to the feature's design record, name the data owner and update it when exports gain email delivery or third-party storage. Those changes add new data recipients and credential paths. The original browser/API diagram no longer covers the whole feature. A useful review asks what changed in authority and data movement, not merely whether the old document still exists.

A predictable object key is not intrinsically a vulnerability. It becomes an access flaw when possession or substitution of that key bypasses the required object binding or access check. Test the authorization decision with a known other-tenant key; randomness can reduce guessing but cannot replace that decision.

Teaching decision record: server derives tenant-red from the authenticated actor's permitted memberships, validates export role and date range, then creates job J7 with immutable tenant-red scope. Worker reads scope by J7 and queries only red invoices. File F7 is bound to J7 and tenant-red. Download authorization checks that binding. A red user who substitutes F8 from tenant-blue receives no file. This is an original design example; production details need transaction, storage and expiry review.

A new requirement emails the export link to any address typed into the browser. Identify the new boundary, one abuse case and a control/test pair. Assume invoice exports contain confidential business data.

The new recipient is an external data destination chosen by the caller. An authorized user or compromised account could send confidential exports to an unintended address. Define who may select recipients, whether recipients must be verified members and whether links are bearer or identity-bound. Test a non-approved recipient and a valid approved recipient. Record residual risk from authorized forwarding rather than claiming email verification prevents all sharing.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Misconception 1: encryption replaces authorization. Encrypted storage can still deliver decrypted data to the wrong authenticated user. Misconception 2: a threat model is a list of scary outcomes. A useful model names actors, paths, assets and tests that can confirm a control.

Evidence class: recommended. Original practice.

How would you threat-model an invoice export in ten minutes?

Strong answer: I would map the actor, tenant scope, queue, privileged worker and download path, then test where authority could widen. I would prioritize cross-tenant reads and file access, attach controls to those decisions and preserve allowed export behavior.

Follow-up: What changes if the download link is intentionally a bearer capability?

Weak answer indicators: Trusting browser tenant IDs; listing encryption as the answer to every threat; no positive tests or residual-risk statement.

Technical references: OWASP threat modeling; OWASP authorization. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.