A Notes application lets Alice save Quarterly budget draft as note 1. Bob signs in to his own account, requests GET /notes/1, and receives Alice’s note because the server checks that Bob is logged in but never checks whether Bob owns note 1. Bob needed neither Alice’s password nor special access, only a predictable identifier. If Bob requests note 1, should the API return Alice’s content? The small local example below shows the insecure request and response:
This code returns Alice’s JSON record while identifying Bob as the acting user. The observable failure is broken access control, where the server permits an authenticated person to perform an action outside that person’s permission. The immediate prevention is a server-side ownership check before reading the note, and the detection signal is a log entry recording Bob, note 1, and a denied authorization decision. We will keep repairing this one Notes application, so every security rule stays connected to a request, a piece of code, and a way to verify the repair.
The missing ownership check matters because the browser is outside the API server’s trust boundary. A trust boundary is the point where the application receives data or an instruction that another party can influence, so the server must validate it and apply its own rules. Bob’s cookie and requested note ID cross from an untrusted client into the server; the API then sends a database query only after making the authorization decision.
The same application has more than one entry point. An unauthenticated internet user can submit login data or create a note. A low-privilege user such as Bob can supply note IDs and note text after login. A compromised dependency can enter during the build when the package registry supplies code that the server will later run. The assets worth protecting are active sessions, Alice’s notes, server secrets, and logs that tell us which requests occurred. The diagram follows each input to the component that must decide whether to trust it: