07.03 · Concept
Security Boundaries & Failure Modes
Locate every place your system decides 'may this actor do this', and confirm the decision is made on the server, on every path.
Broken access control usually hides in alternate paths: APIs, jobs, admin tools, resolvers, downloads, cache reads and object fetches. Treat every protected action as a server-side authorisation decision over actor, resource and action. The UI may guide users, but it cannot be the boundary that protects data or effects.
What this lesson answers
- where should authorisation checks happen in a user system
- why frontend checks are not a security boundary
- how to find missing access control paths
Notes
A security boundary is any line where the system must decide whether an actor is allowed to do something. In a user system, those decisions appear in obvious places like HTTP handlers, but also in background jobs, admin tools, webhooks, direct object fetches, file downloads, GraphQL resolvers, message consumers, cache reads, and database queries. The important question is not “does the UI hide the button?” but “what happens if a caller sends the forbidden request anyway?”
The mental model is to trace every capability from input to effect. For each operation, name the actor, the target object,…
Common questions
- What counts as a security boundary in a user system?
- A security boundary is any point where the system decides whether an actor may perform an action on a resource. That includes request handlers, service methods, object reads, queries, file access, background workers, admin interfaces and message consumers. The boundary is the server-side decision, not the screen that made the action easy to start.
- Why is hiding a button in the UI not enough?
- The browser is controlled by the user. They can alter requests, replay calls, change object identifiers or call the API without using the interface at all. UI restrictions are useful for clarity and reducing mistakes, but every forbidden operation still needs a server-side authorisation check before the protected effect happens.
- Is a login check the same as authorisation?
- No. Authentication establishes who the caller is. Authorisation decides whether that caller may do a specific thing to a specific resource in the current state. A logged-in user may still lack ownership, tenant access, role permission, object-level access or permission to trigger a particular transition.
Short definition: what is Security Boundaries & Failure Modes?