Practical Threat Modeling with Trust Boundaries and Abuse Cases

Threat modeling is most useful before a vulnerability becomes a patch request. It gives a team a structured way to ask how a system can be misused, which assumptions are security-sensitive, and where defenses should exist.

A useful threat model does not need to be a large document. For many services, a one-page data-flow sketch plus a prioritized set of abuse cases is enough to improve design decisions.

Begin with assets and security goals

Start by identifying what the system is trying to protect.

Assets might include:

• customer data;
• authentication sessions;
• money or credits;
• source code and build artifacts;
• administrative actions;
• service availability;
• integrity of audit records.

Turn each important asset into a security goal. “Customer data” is vague; “a user must only read documents they are authorized to access” is actionable.

Security goals make later threats easier to evaluate because the team can ask which goal an abuse case violates.

Draw data flows, not deployment art

A threat-model diagram should show how data and authority move through the system.

Include:

• users and external actors;
• public endpoints;
• application services;
• databases and object stores;
• queues or event brokers;
• third-party APIs;
• administrative interfaces;
• identity providers.

Keep the diagram simple enough to discuss. A detailed infrastructure diagram can obscure the security relationships that matter.

Mark trust boundaries

A trust boundary exists where data or control crosses between contexts with different trust assumptions.

Common boundaries include:

• browser to server;
• public internet to private service;
• application to database;
• user-controlled file to parser;
• CI runner to production deployment;
• one tenant’s data to shared application logic;
• application to third-party API.

For every crossing, ask who controls the input and what validation or authorization occurs after the crossing.

Do not label an internal network as “trusted” and stop reasoning. A compromised service, stolen workload credential, or server-side request forgery can turn an internal endpoint into an attack path.

Describe attacker capabilities

Threats become clearer when the attacker has concrete capabilities.

Examples:

• can create a normal user account;
• controls request parameters and headers;
• can upload files;
• can cause a victim to open a crafted link;
• can observe their own tenant’s responses;
• can trigger repeated requests;
• does not possess administrator credentials.

This avoids both extremes: assuming an omnipotent attacker, which produces unhelpful scenarios, or assuming attackers follow normal UI paths, which misses obvious abuse.

Write abuse cases as short stories

An abuse case describes how an attacker could violate a security goal.

A useful format is:

Given: attacker capability and starting access
When: attacker manipulates a flow or assumption
Then: protected asset or security property is affected

For example:

Given: a normal authenticated account
When: the caller changes a document ID in a request
Then: the API returns another tenant's document

The mitigation is not “validate input.” The core control is object-level authorization on every request that loads the document.

Specific abuse cases lead to specific defenses.

Separate prevention, detection, and recovery

Not every threat can be eliminated completely.

For each important abuse case, consider three layers:

Prevention

Authentication, authorization, input validation, least privilege, isolation, rate limits, cryptographic verification, and safe defaults.

Detection

Security logs, anomaly signals, integrity checks, alerting, and audit trails.

Recovery

Credential rotation, revocation, rollback, backup restoration, incident procedures, and ways to limit ongoing damage.

A system that only prevents known attacks can be fragile when a new failure mode appears.

Prioritize by plausible impact and reachability

Threat modeling can generate more ideas than a team can fix immediately.

Prioritize scenarios based on:

• impact if successful;
• how reachable the attack surface is;
• attacker prerequisites;
• existing controls;
• ease of detection and recovery.

Avoid false precision. A simple high/medium/low ranking with written reasoning is often more useful than a complicated risk equation built from uncertain numbers.

High-impact, internet-reachable paths with weak controls deserve attention before theoretical attacks that require administrator access and physical possession of a host.

Turn mitigations into verifiable work

A mitigation should be testable.

Weak:

Make uploads secure.

Better:

Reject files larger than the configured limit before parsing.
Store uploads outside the executable web root.
Determine allowed media types from validated content, not only the filename.
Run parsing with reduced privileges.

Each statement can become a test, configuration review, or code change.

Threat models provide the most value when their conclusions enter the normal engineering backlog instead of remaining in a security document.

Revisit the model when boundaries change

You do not need a full threat-model workshop for every code change.

Review the model when a change introduces a new:

• external integration;
• privileged role;
• authentication flow;
• data store;
• tenant boundary;
• file or URL ingestion path;
• asynchronous consumer;
• public endpoint;
• deployment or secret-management mechanism.

Those changes alter trust assumptions and can create new attack paths even when individual code changes look small.

Common pitfalls

Listing generic threats without system context

“SQL injection” is not useful if the model does not show where untrusted input reaches a query and what controls exist.

Treating authentication as authorization

Knowing who the caller is does not prove they may access a specific object or action.

Ignoring operational identities

Background workers, CI systems, and service accounts can have powerful privileges and deserve their own abuse cases.

Modeling only prevention

Detection and recovery can dramatically reduce impact when prevention fails.

Producing a document nobody updates

Keep the model lightweight enough to revisit during architecture and security-sensitive changes.

Threat modeling as an engineering habit

The goal is not to predict every vulnerability. It is to expose security assumptions while the design is still easy to change.

Map assets and flows, mark trust boundaries, describe realistic attacker capabilities, write concrete abuse cases, and turn mitigations into verifiable engineering work. Done regularly, threat modeling becomes a practical design review rather than a one-time security ceremony.