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.