Part 8 · Security & Trust Boundaries

Most engineers meet security as a list of chores: hash the passwords, turn on TLS, add a rate limiter. That list is real, but it hides the actual subject. Security is not a feature you sprinkle on at the end. It is a way of reasoning about who you trust, with what, and what happens when that trust is misplaced. This part builds that reasoning from first principles, then hangs the familiar chores on it so they finally make sense.

The two ideas everything reduces to

Almost every security decision is an instance of one of two principles.

Trust boundaries. A trust boundary is any line where data or control crosses from a place you control into a place you don’t — or vice versa. The browser-to-server hop is a boundary. So is service-to-database, service-to-third-party-API, and even one microservice calling another. At every boundary you must ask: do I trust what is coming across, and have I proven who sent it? Code inside a boundary can be sloppy; code at a boundary cannot. Naming your boundaries is the single most clarifying thing you can do, because a vulnerability is almost always a boundary you forgot you had.

Least privilege. Every identity — a user, a service, an API key, a running process — should hold the minimum authority needed to do its job, and no more. Least privilege does not stop breaches; it stops a breach from becoming a catastrophe. When the inevitable mistake happens, the question is not “were we compromised?” but “how far could the attacker reach from here?” Least privilege is how you keep that answer small.

        UNTRUSTED                 │  TRUST BOUNDARY  │            TRUSTED
   ┌───────────────┐   request    │                  │   ┌──────────────────┐
   │  the Internet │──────────────┼──► authenticate ─┼──►│  your service     │
   │  (any input)  │              │   + authorize    │   │  (least privilege)│
   └───────────────┘              │   + validate     │   └──────────────────┘
                                  │                  │
            everything here       │   the gate       │    everything here is
            is presumed hostile   │                  │    still presumed fallible

The mental model that matters most

Do not picture a castle wall keeping bad guys out. Picture a building full of locked doors where every room assumes the hallway is hostile. The wall (the perimeter) will eventually be breached; the locked doors (boundaries + least privilege) are what limit the damage. This shift is the difference between perimeter security and defense in depth.

Why “designed in, not bolted on”

You can always add a lock to a door. You cannot add a door to a building that was poured as one solid block. Security retrofits fail for the same reason: by the time the system exists, the trust boundaries are already implied by the architecture, and moving them means moving everything.

A concrete example. If you build a system where every service shares one almighty database credential, you can later try to scope permissions — but the code now assumes it can read and write anything, so scoping it breaks features and nobody dares. The least-privilege decision had to be made when the boundary was first drawn. This is why threat modeling (the last page of this part) belongs at design time, alongside the data model and the API.

So weave the recurring question through every choice: what does this control buy us, and what does it cost? TLS buys confidentiality and integrity on the wire; it costs latency, certificate management, and operational complexity. MFA buys resistance to stolen passwords; it costs user friction and a recovery-flow headache. There is no free security — only trades you make deliberately or trades that get made for you by an attacker.

The roadmap

The six pages ahead walk the boundary from the outside in, then zoom out to threats:

1. Authentication — who are you? Proving identity with factors you know, have, or are; sessions versus tokens; and why passwords must be salted and slow-hashed, never stored as written.
2. Authorization — what may you do? Once identity is proven, deciding permitted actions with RBAC, ABAC, and ACLs — and enforcing least privilege at the right layer.
3. OAuth & JWT — delegating access without sharing passwords (OAuth2 and OIDC), and the anatomy of a JWT, including the statelessness it buys and the revocation problem it costs.
4. Encryption in Transit & at Rest — protecting data on the wire (TLS) and on disk, the symmetric/asymmetric split, and the key management that makes or breaks all of it.
5. Secrets Management — where credentials live, how they rotate, how they reach a process, and how to keep one leaked secret from becoming a total compromise.
6. Threat Modeling & Abuse Prevention — STRIDE, validating untrusted input, and defending against DDoS and abuse — the discipline that ties the boundaries together.

What this buys us, and what it costs

A trust-boundary mindset buys you a system whose failures are contained and predictable: you can point at a diagram and say where the gates are and what each side assumes. It costs you upfront thinking, some convenience, and the discipline to keep boundaries honest as the system grows. That trade is overwhelmingly worth it, because the alternative isn’t “no cost” — it’s a cost paid later, all at once, by someone else.

Begin where every request begins: at the gate that asks who are you? — continue to Authentication →.

Check your understanding

1. Define a trust boundary in your own words, and give two examples from a typical web system.
2. Least privilege doesn’t prevent breaches — so what does it actually accomplish?
3. Why is security genuinely harder to add to an existing system than to design in from the start?
4. Contrast perimeter security with defense in depth using the “castle wall vs. locked doors” image.
5. Pick any one control (TLS, MFA, rate limiting) and state what it buys and what it costs.

Show answers

1. A trust boundary is any line where data or control crosses from a place you control into one you don’t (or vice versa) — the point where you must ask do I trust what’s coming across, and have I proven who sent it? Examples: the browser-to-server hop, service-to-database, service-to-third-party-API, even one microservice calling another. A vulnerability is almost always a boundary you forgot you had.
2. It doesn’t prevent breaches — it stops a breach from becoming a catastrophe. When the inevitable mistake happens, the question isn’t “were we compromised?” but “how far could the attacker reach from here?” Least privilege keeps that answer small by giving every identity the minimum authority it needs.
3. By the time the system exists, the trust boundaries are already implied by the architecture, and moving them means moving everything — you can add a lock to a door, but not a door to a building poured as one solid block. If every service shares one almighty database credential, scoping it later breaks features and nobody dares, so the least-privilege decision had to be made when the boundary was first drawn.
4. Perimeter security is the castle wall keeping bad guys out — but the wall will eventually be breached, and then the attacker has the run of the place. Defense in depth is a building full of locked doors where every room assumes the hallway is hostile, so breaching the perimeter doesn’t hand over everything — the locked doors (boundaries + least privilege) limit the damage.
5. Open-ended — e.g. TLS buys confidentiality and integrity on the wire and authentication of the server; it costs latency (an extra handshake round trip), certificate management, and operational complexity. (MFA buys resistance to stolen passwords and costs user friction plus a recovery-flow headache; rate limiting buys survival under overload and abuse protection and costs rejected legitimate requests at the margin.) There is no free security — only trades you make deliberately.