Threat-Model a Small Feature Before It Ships

Small features cross trust boundaries too. An “export report” button may authorize access, query sensitive rows, write a temporary file, send telemetry, and expose a download URL. Reviewing only the button and query misses most of the attack surface.

A lightweight threat model can fit in one page when it stays attached to a specific data flow. The goal is not to list every theoretical attack. It is to identify protected assets, plausible misuse, controls, residual risk, and the evidence required before release.

State the feature and security decision

Write one sentence describing who can perform which action on what asset and under which conditions. For example: “An authenticated account administrator can export a bounded set of its own billing records as a temporary CSV.”

Then state exclusions. Perhaps organization-wide exports, scheduled exports, and shared public links are not part of this feature. Scope prevents the model from becoming a generic security checklist.

List the assets that would matter if disclosed, modified, destroyed, or made unavailable:

• billing record content;
• tenant boundary and authorization policy;
• export job state;
• temporary artifact and download capability;
• service capacity;
• audit or diagnostic events.

Rank consequences in the system's context. Avoid inventing financial estimates or compliance conclusions. The model supports technical decisions; qualified owners evaluate legal obligations.

Draw actors, components, and data flow

Use the smallest diagram that shows the browser or client, API boundary, authorization service, database, job queue, worker, object storage, and logging or notification systems. Label data stores and communication paths.

Mark trust boundaries where identity, privilege, ownership, process, machine, network, or provider changes. A call inside one cloud account can still cross from an internet-facing process to a privileged worker. “Internal” is not an authentication mechanism.

For each flow, record:

• data and classification;
• authentication and authorization decision;
• transport protection;
• validation and output encoding;
• persistence and retention;
• failure and retry behavior;
• telemetry emitted.

The OWASP Threat Modeling Cheat Sheet presents threat modeling as a structured analysis of what is being built, what can go wrong, what will be done, and whether the work was sufficient. Keeping those questions tied to the diagram prevents checklist drift.

Write abuse cases at each boundary

Describe an attacker goal and path, not only a control name. For the export example:

• A user changes a tenant identifier to export another account's rows.
• A former administrator reuses a download URL after access is revoked.
• A formula-like cell triggers behavior when the CSV opens in a spreadsheet.
• Repeated exports exhaust worker, database, or storage capacity.
• A retry creates several artifacts and notifications for one request.
• Logs capture row content or the bearer download capability.
• A worker follows an attacker-controlled storage path.

Include accidents and compromised dependencies, not only malicious users. A misconfigured bucket or over-privileged worker can expose the asset without a crafted request.

Frameworks such as STRIDE can prompt missing categories, but do not force one threat into every category. A short set of feature-specific abuse cases is more actionable than a large generic list.

Map preventive, detective, and recovery controls

For each abuse case, choose controls at the authoritative boundary. Tenant ownership belongs in the server-side query or authorization layer, not only a hidden client field. Resource limits belong in queue and worker policy, not only a disabled button.

Distinguish control roles:

• Prevention blocks or constrains an action.
• Detection reports a condition after or while it occurs.
• Mitigation reduces impact.
• Recovery restores a trusted state.

An expiring download URL reduces the exposure window but remains a bearer capability until expiry or revocation. Encryption at rest protects stored bytes under its key and access model; it does not repair overbroad application authorization.

Record residual risk after controls. If administrators can legitimately export sensitive data, a compromised administrator session remains a risk. Stronger authentication, reauthentication for export, notifications, rate limits, and audit events may reduce it, but no one control makes export “secure.”

Turn threats into verification evidence

Every selected control needs a test or observation:

• cross-tenant identifiers are denied at the authoritative query boundary;
• revocation invalidates outstanding download access within the defined window;
• CSV output neutralizes spreadsheet formula execution according to the supported consumer model;
• idempotency produces one job for concurrent identical requests;
• rate and size limits hold under parallel requests;
• storage policy denies public access;
• logs and traces contain no rows, tokens, or download URLs;
• cleanup removes expired artifacts and retries failed cleanup safely.

Test failure paths: queue unavailable, worker crash after upload, notification failure, storage timeout, and partial database results. Confirm that errors do not expose internal paths or leave orphaned sensitive artifacts indefinitely.

Assign ownership and update triggers

Record the model with the feature design, not in a detached security folder nobody revisits. Name owners for controls, tests, monitoring, retention, and incident response. Link assumptions to configuration or contracts where possible.

Update the model when the data classification, actor, provider, storage location, authentication method, link lifetime, batch size, or retry path changes. A new integration can create a trust boundary without changing the visible feature.

The threat model is ready when the team can explain the protected assets, the most credible paths to harm, the controls at each boundary, how failures are detected and recovered, and which residual risks are accepted. Its value is the changed design and test plan, not the number of threats in the document.