SecLab
Secure Design & Threat ModelingconceptDifficulty 3/521 min

Trust boundaries: the only place validation means anything

Objective: After this lesson you can draw a system's trust boundaries and say what each one must check.

V15A06:2025Microsoft SDL
Step 1 of 4 · read7 min

A boundary is where the trust level changes

The question "where do I validate input" has a precise answer, and it is not "everywhere": validate at each trust boundary, and only there.

A trust boundary is where data moves from a region you control less into one you control more — or the reverse. It is not an architectural layer and not a service; it is a place where the trust level changes.

Six boundaries of a typical web system, of which the last four are usually missed:

BoundaryFrom → toWhat it must check
Browser → APIUntrusted → trustedAuthentication, authorisation, validation, size
API → databaseTrusted → trustedParameterisation (an interpreter boundary, not a trust one)
API → external APITrusted → untrustedDo not over-send data, validate the destination (SSRF)
External API → APIUntrusted → trustedValidate the response — module 7
Background job → databaseTrusted → trusted, but not over HTTPIt bypasses every middleware
A privileged user → another's dataTrusted → trusted, but the subject changesThis is module 2's boundary

The last two are the most important and least drawn:

A background job is a boundary because it passes through no middleware. Every control you placed in the HTTP pipeline — authentication, authorisation, rate limiting, validation — does not exist on a job's path. This is why RLS in rls-second-layer has distinct value: it is the one layer sitting behind this boundary.

A subject change is a boundary with no physical shape, which is why it gets missed. When an admin reads a user's data it crosses no new network — but who may see it has changed, and that is a boundary needing a check and a log line.

And the most important thing about boundaries: a control placed at the wrong boundary is a control that does not exist. Validating in the frontend is validating on the wrong side of the first boundary. Checking authorisation in middleware is checking on the wrong side of the sixth — exactly what authn-vs-authz argued.

View path

Comments

Join the discussion
Sign up to comment

Commenting needs an account with at least one completed lesson. That condition is what keeps this thread worth reading: every point belongs to someone who can be asked back, and reputation accrues over time.

Sign upSign in

You can still read every comment below without an account. Signing in brings you back to this exact spot, not to the top of the page.

Loading comments…