THREAT-MODEL WORKSHEET — FICTIONAL COMPLETED EXAMPLE
Educational example, not an assessment of a real product or employer.
Review date: 2026-10-17. No security tests have been executed.

REVIEW CONTEXT
System: Fictional multi-tenant invoicing service.
Scope: Invoice list/search, detail reads, writes, export creation/retrieval, membership checks.
Exclusions: Billing integrations and backup recovery. These require separate review.
Owner: Example application team. Reviewers: example security and engineering roles.
Business purpose: Let each organization manage its own invoices.
Assets: Invoice identifiers, amounts, tenant membership, export files, audit events.
Sensitivity: Treat invoices and membership as confidential within their tenant.
Actors: Alpha and Beta administrators and members, anonymous caller, revoked member.
Policy: Members list/read all invoices in their own tenant. Admins also create,
update, delete and export. Tenant admins have no cross-tenant privilege.

MODEL
Untrusted client -> authenticated API -> membership/permission check -> data store.
API -> tenant-bound job queue -> export worker -> tenant-bound file store.
Export retrieval -> current membership and admin permission -> authorized file.
Boundaries: Client/API; API/data store; API/worker; worker/file store; one tenant/another.
Assumptions: Identity is verified; the membership source is current. Both need evidence.
Dependencies: Identity provider, membership service, database, queue, object storage.

TM-001 — CROSS-TENANT INVOICE ACCESS
Scenario: A Beta caller supplies an Alpha invoice ID or reaches Alpha data via list/search.
Preconditions: Valid Beta credential and an Alpha object ID or search term.
Boundary/impact: Tenant boundary; unauthorized invoice disclosure or modification.
Existing controls: Tenant-scoped repository is proposed; no execution evidence exists.
Response: Mitigate with verified tenant scope on all read/write paths and result aggregates.
Action/owner: Application team implements scoped queries and regression checks.
Target: Before exposing the reviewed endpoints; an example decision, not a universal SLA.
Verification: AUTHZ-003/004/005/006/007/013/014, including response and stored-state checks.
Allowed lists must include the expected seeded own-tenant invoices and counts;
returning an empty collection is not sufficient isolation evidence.
Residual risk: Unreviewed endpoints and backup flows remain outside this model.
Status: Open; no verification evidence. Revisit when a query or access path changes.

TM-002 — UNVERIFIED TENANT SELECTION
Scenario: Alpha admin selects Beta's tenant ID in the URL.
Preconditions: Valid Alpha admin credential; no Beta membership.
Boundary/impact: Client-supplied selector to authorization context; tenant impersonation.
Existing controls: Current-membership check is a requirement, not a verified control.
Response/action: Mitigate; application team binds the selector to verified membership.
Verification: AUTHZ-015 must deny without returning Beta data or metadata.
Status: Open; target before endpoint release. Revisit identity/context changes.

TM-003 — EXPORT ACCESS AND PROPAGATION
Scenario: Creation checks access but a worker or later download mixes tenants.
Preconditions: Job scheduling or an export ID; different actors may retrieve later.
Boundary/impact: API/worker/storage; bulk invoice disclosure.
Existing controls: Tenant-bound job/file ownership is proposed, not demonstrated.
Response/action: Mitigate; application team preserves verified tenant context and
rechecks permission at retrieval. Never treat an object ID as authorization.
Verification: AUTHZ-018/019/020/021; inspect queued context, file rows and metadata.
Residual risk: Signed-URL lifetime and offboarding of already downloaded files need review.
Status: Open; target before export release. Revisit worker/storage/URL changes.

TM-004 — STALE MEMBERSHIP
Scenario: Removed Alpha member reuses a credential issued before removal.
Preconditions: Valid prior credential and revoked tenant membership.
Boundary/impact: Credential verification versus current authorization; continued access.
Existing controls: Example policy requires revocation on the next request; no evidence yet.
Response/action: Mitigate; identity/application teams check current membership and
review caching/invalidation against that explicit next-request requirement.
Verification: AUTHZ-017 with the same credential before and after revocation.
Status: Open; target before release. Revisit cache or session-policy changes.

TM-005 — ROLE ENFORCEMENT
Scenario: A read-only member attempts invoice mutation or an administrative action.
Preconditions: Active member credential and an accessible own-tenant object.
Boundary/impact: Member/admin boundary; invoice integrity and export confidentiality.
Existing controls: Documented role policy; implementation unverified.
Response/action: Mitigate; application team enforces permission at each operation.
Verification: Allowed controls AUTHZ-001/002/009/010/012 plus denials 008/011/016.
Status: Open; target before release. Revisit roles and new operations.

OPEN QUESTIONS
How are cache keys tenant-scoped? Who can restore tenant data? What invalidates
export URLs after membership changes? Which evidence demonstrates each proposed control?
No acceptance is recorded: the example decision-maker must review residual risk.

Companion guide: https://www.brandoneckert.com/threat-model-worksheet/