---
{
  "title": "Trust boundaries",
  "summary": "A trust boundary separates components or actors operating under different security assumptions.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Threat Modeling",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

A trust boundary separates components or actors operating under different security assumptions. Crossing it requires an explicit decision about identity, permissions, data handling, or integrity. A boundary may exist within one host or cloud account, not only between the internet and an internal network.

## A practical example

A web server calls a document processor with user-supplied files. The processor is isolated and receives a narrow request schema because document content is untrusted even though the request originated from an internal server.

## What to check

Map changes in ownership, privilege, authentication, and data origin. Identify which component enforces each decision and verify that a trusted caller cannot accidentally pass through attacker-controlled authority.

## A common pitfall

Calling traffic internal does not make every field trustworthy. A trusted service can relay untrusted input or act with more privilege than the original caller.

## Think it through

Does a shared network remove a trust boundary between tenants?

**Answer:** No. Tenant ownership and authorization remain separate even when infrastructure is shared.

## Trust changes when authority changes

A fictional media application sends uploaded documents from a web server to a conversion worker. The web server is trusted to submit jobs, but the document bytes still originate with users. If the worker treats every field as trusted because the caller is internal, the original untrusted content gains the server's authority without a deliberate decision.

Draw boundaries around differences in identity, ownership, privilege, and data origin. Two processes on one machine can have a boundary if one handles untrusted files and the other holds deployment credentials. Conversely, moving traffic through an internal network does not automatically remove the need for authentication and authorization.

At each crossing, identify the enforcement point. A worker might accept a narrow job schema, operate in an isolated directory, and return a defined result. The web application should validate that result before making it authoritative. Trust is directional and specific: permission to process a document does not imply permission to choose arbitrary filesystem paths or execute unrelated tasks.

## Annotate one data-flow diagram

For the media example, label the browser, web server, queue, worker, storage, and download service. Mark the origin of each value and the credentials used on each connection. Ask where a user-controlled filename becomes a storage path and where a worker result becomes a public download.

Then consider a compromised or buggy worker. What could it access, and which component would reject an invalid result? Use that thought experiment to narrow permissions and clarify contracts. A well-described boundary states what is trusted for a particular purpose and what remains untrusted, making the system easier to review than broad labels such as internal, partner, or secure network.

## Related concepts

- [[threat-modeling]]
- [[least-privilege]]
- [[zero-trust]]