07.02 · Lecture
The Trust Boundary
Draw the line between what the client may be trusted with and what it may not, and place your secrets on the right side of it.
The trust boundary separates attacker-readable client code from server-side code that can safely hold secrets and enforce decisions. Browsers, apps and devices can be inspected, patched and replayed, so credentials and authorisation checks belong behind your API, with public identifiers allowed client-side only when designed for that use.
What this lesson answers
- what secrets can go in frontend code
- where should API authorisation be enforced
- are environment variables safe in browser bundles
Notes
The Trust Boundary — The trust boundary exists to separate code and data an attacker can inspect or control from code and data protected by your infrastructure; without it, client-side secrets, authorization rules, and hidden assumptions become extractable and bypassable.
Key Concepts: - A browser, mobile app, desktop app, or IoT device is outside the trust boundary because the user can inspect traffic, patch binaries, read storage, or run a debugger such as Chrome DevTools or Frida.
References
Common questions
- Can I put a secret API key in a private frontend repo?
- No. A private repo only protects source access before deployment. Once frontend code is shipped, users can download bundles, inspect traffic and read runtime state. Secret keys for services such as payments, cloud accounts or signing must stay in server-side code, with the client calling your backend instead.
- What is safe to expose to a browser or mobile app?
- Expose values that are intentionally public and cannot grant privileged access on their own, such as publishable payment keys, browser-restricted map keys or project identifiers. Treat them as identifiers, not credentials. Anything that can create charges, read private data, sign tokens or administer infrastructure belongs inside the trust boundary.
- Why is hiding an admin button not enough security?
- UI checks improve usability, not enforcement. A user can call the underlying API directly, modify requests, change local state or replay traffic. The API must verify identity, role and resource access before performing privileged actions. The client may suggest intent, but the server must make the decision.
Short definition: what is Trust Boundary?