In a single-page trading app whose trader-vs-supervisor route guard ships in downloaded JavaScript, where does the trust boundary actually belong?

## The mistake A team models their trading front end. The single-page app has two personas - a trader who can enter orders, and a desk supervisor who can approve orders above a limit - and the router refuses to render the approval screens unless the logged-in user's role claim says supervisor. On the diagram, someone draws a trust boundary between the trader part of the app and the supervisor part, both inside the browser box. It looks tidy, and it is wrong in a way that hides the most likely attack on the system. ## Why a boundary cannot live inside code you ship A trust boundary is only meaningful where an enforcement point you control sits at the crossing. Once the server has answered with a bundle, execution moves to hardware, an operating system, a browser and a set of extensions and developer tools that belong to the user. On that side the user can: change in-memory state so the role flag reads supervisor, set a breakpoint and step past the guard, load a patched bundle, or drop the app completely and send requests with a scripted client. Nothing in the delivered code observes any of this, and nothing reports it. So from the server's point of view the browser is **one zone**, not two. The trader and supervisor "zones" the diagram drew are two arrangements of pixels inside the same untrusted process. Delivering that bundle over TLS does not change it: transport integrity protects the code in flight, not its execution afterwards. Neither does minification or obfuscation - those raise effort, not authority, and an attacker does not need to read the guard to bypass it when they can call the endpoint the guard was hiding. ## What the corrected diagram looks like Draw one boundary between the browser (everything in it, both roles, session storage included) and the server API. Then the crossings you enumerate are the API calls, and the questions become the right ones: - Which endpoints does an *authenticated trader* reach if they simply send the request the supervisor UI would have sent? Every one of them is an elevation-of-privilege candidate until the server re-decides the role on its own authority. - What fields does the client supply that the server should be deriving instead - the acting role, the desk, the approval limit, the identity of the approver? - What does the audit record say if the client is lying about who approved what? Non-repudiation depends on the server writing what it decided, not what the client claimed. The client guard still belongs on the diagram, but annotated as **non-enforcing / UX only**. That annotation is doing real work: diagrams outlive the people who drew them, and the next reviewer who sees a line and no caveat will assume the split is enforced and skip the very threats it fails to stop. ## The adversary this reframing exposes The original diagram implicitly modeled an outsider - someone who must first steal a session to reach anything. The corrected one puts the *legitimate authenticated user* on the untrusted side, which is where the interesting attack lives here: a trader holding entirely valid credentials, approving their own oversized order or raising their own limit. Nothing about that request is anomalous at the transport or session layer, so the only place it can be stopped is a server-side decision at the crossing. Note also the direction the asset sits in: money and order integrity, not confidentiality of customer data - so the threats that dominate are tampering and elevation of privilege, and the control that matters is a server-side decision plus an audit trail the client cannot influence. ## The general rule to state The moment code or data crosses to a party you do not control, you cannot place another boundary beyond it. Every enforcement point must be on your side of the last crossing. This generalises past browsers to any component you hand out: a partner's batch job you deliver, an on-premises agent installed in a customer's estate, a widget embedded in someone else's page. In each case the diagram may show internal structure for clarity, but only the flow back into a system you operate can carry a boundary. ## What good answers add Strong candidates also say what the client-side guard is *for*: it stops honest users from wandering into functions they cannot use, reduces support noise, and keeps the interface truthful. That is a legitimate reason to keep it. It just is not a security control, and the diagram should say so in as many words.