Security · 32 min read
Threat Models and Trust Boundaries
Why security is never absolute: you state who might attack, what you protect, and where trust stops, then choose controls against that model.
Why this exists
Encryption, TLS, and login systems answer how to protect data. They do not answer what you protect against. Without that answer, teams buy tools and still fail.
A threat model names assets, adversaries, and goals. A trust boundary marks where you stop believing data or actors without checks. Together they turn vague fear into design decisions.
This lesson is the foundation that later security pages assume. It teaches why "secure" always means "secure against a stated model," not a magic property of a product.
Axioms & primitives
- 01Security is relative to a threat model: assets, adversaries, capabilities, and goals.
- 02A trust boundary is a place where data or control crosses between parties with different trust.
- 03Confidentiality, integrity, and availability (CIA) are distinct goals that trade off under attack.
- 04Controls exist to reduce risk against the model. They do not erase every possible harm.
- 05Assumptions are part of the model. Unstated assumptions become silent failure modes.
- 06Moving a trust boundary (for example, trusting a CDN or a library) changes what you must verify.
Learning objectives
After this lesson you should be able to:
- Write a short threat model for a web login that names assets, adversaries, and at least three concrete threats.
- Draw trust boundaries on a browser-to-database request path and state what you verify at each crossing.
- Give one example each for a confidentiality, integrity, and availability failure with different controls.
- Explain why a system can be "encrypted" and still fail its threat model.
- Identify one hidden assumption in a design and say what happens if that assumption is false.
Progressive depth
Read the layers in order for a full explanation. Or open the layer you need.
Intuition
Ask a blunt question first: secure against whom, doing what, to which thing you care about?
A cafe attacker who reads Wi-Fi traffic is not the same adversary as a stolen laptop thief, a malicious insider, or a botnet that floods your login page. Controls that stop one often miss another. Encryption helps against the cafe eavesdropper. It does little against a flood. A password lock on a laptop helps against the thief. It does not stop a phishing site that tricks the user.
Trust boundaries are the places where those stories change. When a browser sends a request to your server, you should not trust the client body as gospel. When your server talks to a payment vendor, you should not trust every callback without verification. When a library parses a file, you should not assume the file is kind.
Once you name assets, adversaries, and boundaries, security work becomes design: pick controls that match the model, and write down what you still accept.
Formal shape
A practical threat model answers four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job? OWASP and industry practice frame the work this way. You do not need a heavyweight process to start. You need written answers.
Assets are things with value: credentials, personal data, money movement, uptime, reputation. Adversaries have goals and capabilities: remote network attacker, malicious user with an account, compromised dependency, physical access.
The CIA triad names three properties. Confidentiality: only authorized parties learn the content. Integrity: data and software are not altered without detection. Availability: legitimate use can proceed. Attacks often trade one for another. Encrypting a disk can hurt availability if keys are lost. Strict integrity checks can reject needed updates if misapplied.
STRIDE is a common prompt set: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Use it to brainstorm. Map each relevant item to an asset and a boundary.
A trust boundary crossing needs a policy: authenticate the peer, authorize the action, validate input, encrypt the channel, log the event, or refuse the request. Crossing without a policy is an implicit trust decision.
Trust boundaries on a request path
Click a stage to see what you verify at that boundary. Matches the Browser to Database exercise on this page.
Loading diagram...
Select a stage to read the boundary detail.
Worked examples
Example A: password login for a web app. Assets include session tokens, password hashes, and user email. Adversaries include network eavesdroppers, credential stuffers, and XSS thieves. Boundaries include browser to TLS terminator, app to database, and app to email provider. Controls include TLS, hashed passwords, HttpOnly session cookies, rate limits, and input encoding. A model that ignores XSS will over-praise TLS and still lose sessions.
Example B: public static marketing site with no accounts. Assets are mostly availability and content integrity. A full password vault threat model is waste. Focus on CDN integrity, deploy credentials, and denial of service. The smaller model is not lazy. It is accurate.
Example C: mobile app that stores a token. If the model assumes a trusted device, on-device storage may look fine. If the model includes stolen phones and malware, you need stronger token binding, short lifetimes, and remote revoke. Same feature. Different model. Different design.
Example D: "we use HTTPS, so we are secure." Against eavesdropping on the path to a validated name, HTTPS helps. Against a phishing domain with its own valid certificate, HTTPS does not help. The model must include who the user intends to reach.
Edge cases
Shared fate with vendors: if you trust a cloud identity provider, their outage is your availability incident, and their breach can become your authentication incident. Your model must include that dependency or you will be surprised.
Changing boundaries after launch: adding a reverse proxy, a WAF, or a client-side analytics SDK moves trust. Revisit the model when architecture changes.
Over-modeling: a 40-page threat model that nobody reads fails the "did we do a good job" question. Prefer a living one-pager per service over unread theater.
Under-modeling: "secure by default" slogans with no assets listed hide disagreements. Teams then ship conflicting controls.
Physical and social attacks: many cryptographic controls assume the endpoint is honest. If the model excludes shoulder surfing, malware, and support-desk fraud, say so. Do not pretend AES fixes those.
Compliance maps: SOC2 or PCI checklists are not a threat model. They can inform one. They do not name your adversaries for you.
Mental models
Castle walls and gates
Walls are controls. Gates are trust boundaries where people and goods enter. A gate without checks is a hole even if the wall is thick.
Insurance policy
A threat model is like an insurance policy: it states what is covered and what is excluded. Buying a lock without reading the policy leaves gaps.
Customs checkpoint
At a border, you inspect bags because trust changes. Inside one country you may skip that check. Software needs the same explicit checkpoints.
Weather forecast, not weather control
The model predicts storms (attacks) you care about. Controls are umbrellas. They do not stop all weather, and the wrong umbrella fails the storm you named.
Common misconceptions
Myth
A product is either secure or insecure as an absolute fact.
Reality
Security claims only make sense against a threat model. A home Wi-Fi setup can be fine against casual neighbors and weak against a nation-state.
Myth
Encryption makes a system secure.
Reality
Encryption mainly serves confidentiality (and, with authentication, integrity). It does not stop denial of service, stolen endpoints, or wrong authorization.
Myth
Trust boundaries only exist at the company firewall.
Reality
Boundaries appear between browser and server, app and database, user and admin roles, and between your code and a third-party library.
Myth
If you list every STRIDE category, you are done.
Reality
STRIDE is a prompt list. You still must rank threats for your assets and decide which risks you accept.
Exercises
Work these without looking up answers first. Check yourself against the intent notes.
Exercise 01
Pick a simple notes app with login. List three assets, two adversaries, and three threats. For each threat, name one control and one residual risk you still accept.
Hint: Start from what an attacker would steal or break, not from a list of products you want to buy.
What good looks like
Learner separates assets from controls, names concrete adversaries, and shows that residual risk remains after controls.
Exercise 02
On a path Browser -> TLS -> App server -> Database, mark trust boundaries. For each boundary, state one check that should happen.
Hint: Ask: after this hop, do I still believe the previous hop without verification?
What good looks like
Learner places boundaries at client/server and app/database at minimum, and names authn/authz, TLS validation, or query parameterization style checks.
Exercise 03
A team says their API is secure because all fields are encrypted in the database. Give one CIA goal this may help and two threat classes it does not address.
Hint: Ask what an attacker with a stolen session token can still do.
What good looks like
Helps confidentiality at rest for some threats; fails availability attacks and many authorization/abuse cases; may not stop compromised app servers that decrypt.
Sources & further reading
External references. Prefer primary documents and clear explainers.
Go deeper on your own
These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.
- Threat Modeling ManifestoDeep dive
Shared values and principles for threat modeling practice. Use it to sharpen why boundaries and adversaries matter.
Industry threat-modeling process used in the Security Development Lifecycle. Open it for a concrete workflow.
Data-centric threat modeling guidance from NIST. Use it when you want a formal public-sector reference.