SECURITYATLAS✳

✳ Field lesson F5b / 9 min

Application trust boundaries: why the client UI is never a security gate

Every byte arriving from a browser, mobile app, CLI, or external webhook crosses an application trust boundary and must be treated as untrusted until the server independently authenticates the caller, checks object-level authorization, and validates input against a strict schema.

foundationsapplicationtrust-boundaryowaspCISSP D8Security+ (SY0-701) D2CCSP D4

THE BOUNDARY IS ON THE SERVER

ONE INVOICE.

Change the request. Follow the query. Open the response.
Discover which check keeps another tenant’s data out of your browser.

CALLER → TRUSTED APPLICATIONILLUSTRATIVE SPACE

The same request is available in the complete journeys below. JavaScript adds the spatial view and controls.

Browser → API → query → invoice store → response

Local work at Browser

A hidden link does not bind the request

The normal UI offers invoice 1042. The caller can still construct a request for a different ID or claim a different tenant. The verified session remains tenant A.

Follow the request to see what reaches the browser.
  1. 1 Browser
  2. 2 API
  3. 3 Query boundary
  4. 4 Invoice store

WHO KNOWS WHAT, RIGHT NOW?

The browser’s evidence records delivery, independently of the teaching cutaway.

Signed-in account
Tenant A
Response receipt
Awaiting application response

EDITABLE CLAIM ≠ VERIFIED IDENTITY

Synthetic invoices and requests. No live API, SQL, or authentication runs here. Authentication and HTTPS are held valid; ownership is the variable. The protected example uses a parameterized, tenant-scoped lookup and the same HTTP 404 for unavailable and missing invoices. Other applications may choose a different response policy.

Read every journey, including the broken boundary and its repair

Read your invoice

Requested invoice 1042; caller claims tenant A; verified session remains tenant A.

  1. A hidden link does not bind the request. The normal UI offers invoice 1042. The caller can still construct a request for a different ID or claim a different tenant. The verified session remains tenant A.
  2. Caller-controlled bytes cross the boundary. HTTPS protects this request in transit. It does not make the caller-supplied invoice ID or tenant claim authoritative. The API learns these bytes on arrival.
  3. Bind authority to the verified session. The API uses tenant A from its already validated session. It binds both invoice ID and session tenant as query parameters. The editable tenant claim supplies no authority.
  4. The store receives a parameterized query. Both values are bound data: the requested invoice ID and the verified session tenant A. A row must satisfy both predicates.
  5. A matching row travels back. The store has selected invoice 1042. Its query result travels back to the application. The row belongs to tenant A and satisfies the scoped query.
  6. The application prepares its response. The application prepares HTTP 200 and the selected invoice. The selected row passed the session-bound query. The browser has not received the response yet.
  7. The response reaches the browser. The API already knows the response it generated. The cutaway previews its contents during transit; the browser’s evidence changes only at arrival.

Authorized: tenant A receives its own invoice.

Change the ID: UI-only protection

Requested invoice 1043; caller claims tenant A; verified session remains tenant A.

  1. A hidden link does not bind the request. The normal UI offers invoice 1042. The caller can still construct a request for a different ID or claim a different tenant. The verified session remains tenant A.
  2. Caller-controlled bytes cross the boundary. HTTPS protects this request in transit. It does not make the caller-supplied invoice ID or tenant claim authoritative. The API learns these bytes on arrival.
  3. The server omits the ownership boundary. This deliberately broken handler selects by invoice ID alone. Authentication succeeds, but no ownership restriction is added. Hiding another tenant’s link has no effect on this query.
  4. The store receives a parameterized query. The query safely binds the invoice ID as data, but has no ownership predicate. Parameterization alone does not enforce object-level authorization.
  5. A matching row travels back. The store has selected invoice 1043. Its query result travels back to the application. The omitted ownership restriction allowed a row belonging to tenant B.
  6. The application prepares its response. The application prepares HTTP 200 and the selected invoice. A successful status can represent a disclosure when authorization was omitted. The browser has not received the response yet.
  7. The response reaches the browser. The API already knows the response it generated. The cutaway previews its contents during transit; the browser’s evidence changes only at arrival.

Disclosure: tenant A receives tenant B’s invoice.

Repair: bind the query to the session

Requested invoice 1043; caller claims tenant A; verified session remains tenant A.

  1. A hidden link does not bind the request. The normal UI offers invoice 1042. The caller can still construct a request for a different ID or claim a different tenant. The verified session remains tenant A.
  2. Caller-controlled bytes cross the boundary. HTTPS protects this request in transit. It does not make the caller-supplied invoice ID or tenant claim authoritative. The API learns these bytes on arrival.
  3. Bind authority to the verified session. The API uses tenant A from its already validated session. It binds both invoice ID and session tenant as query parameters. The editable tenant claim supplies no authority.
  4. The store receives a parameterized query. Both values are bound data: the requested invoice ID and the verified session tenant A. A row must satisfy both predicates.
  5. An empty result travels back. The scoped query finds no row. This result does not tell the browser whether another tenant owns the requested ID or the ID does not exist.
  6. The application prepares its response. The application prepares HTTP 404 and “Invoice not found,” without invoice contents. In this protected example, unavailable and nonexistent objects have the same outward response.
  7. The response reaches the browser. The API already knows the response it generated. The cutaway previews its contents during transit; the browser’s evidence changes only at arrival.

Withheld: no invoice matches the caller’s permitted query.

Also claim to be tenant B

Requested invoice 1043; caller claims tenant B; verified session remains tenant A.

  1. A hidden link does not bind the request. The normal UI offers invoice 1042. The caller can still construct a request for a different ID or claim a different tenant. The verified session remains tenant A.
  2. Caller-controlled bytes cross the boundary. HTTPS protects this request in transit. It does not make the caller-supplied invoice ID or tenant claim authoritative. The API learns these bytes on arrival.
  3. Bind authority to the verified session. The API uses tenant A from its already validated session. It binds both invoice ID and session tenant as query parameters. The editable tenant claim supplies no authority.
  4. The store receives a parameterized query. Both values are bound data: the requested invoice ID and the verified session tenant A. A row must satisfy both predicates.
  5. An empty result travels back. The scoped query finds no row. This result does not tell the browser whether another tenant owns the requested ID or the ID does not exist.
  6. The application prepares its response. The application prepares HTTP 404 and “Invoice not found,” without invoice contents. In this protected example, unavailable and nonexistent objects have the same outward response.
  7. The response reaches the browser. The API already knows the response it generated. The cutaway previews its contents during transit; the browser’s evidence changes only at arrival.

Withheld: no invoice matches the caller’s permitted query.

Ask for a missing invoice

Requested invoice 9999; caller claims tenant A; verified session remains tenant A.

  1. A hidden link does not bind the request. The normal UI offers invoice 1042. The caller can still construct a request for a different ID or claim a different tenant. The verified session remains tenant A.
  2. Caller-controlled bytes cross the boundary. HTTPS protects this request in transit. It does not make the caller-supplied invoice ID or tenant claim authoritative. The API learns these bytes on arrival.
  3. Bind authority to the verified session. The API uses tenant A from its already validated session. It binds both invoice ID and session tenant as query parameters. The editable tenant claim supplies no authority.
  4. The store receives a parameterized query. Both values are bound data: the requested invoice ID and the verified session tenant A. A row must satisfy both predicates.
  5. An empty result travels back. The scoped query finds no row. This result does not tell the browser whether another tenant owns the requested ID or the ID does not exist.
  6. The application prepares its response. The application prepares HTTP 404 and “Invoice not found,” without invoice contents. In this protected example, unavailable and nonexistent objects have the same outward response.
  7. The response reaches the browser. The API already knows the response it generated. The cutaway previews its contents during transit; the browser’s evidence changes only at arrival.

Withheld: no invoice matches the caller’s permitted query.

Helpful first: Least privilege, defense in depth, and Zero Trust boundaries · Networks in one request: DNS, TCP, TLS, and HTTP

Key points

  • Locate the exact trust boundaries in a modern web or microservice architecture
  • Explain why client-side UI hiding and browser JavaScript validation are UX conveniences rather than security controls
  • Prevent Broken Object Level Authorization (BOLA / IDOR) and injection by binding server-side checks to the authenticated session context

Hiding the button in React does not lock the API endpoint

During an Application Security review at Meridian Space & Robotics (chronos.orbital), Principal Security Architect Vera Vance inspects the customer telemetry portal. Only Flight Directors are supposed to trigger the POST /api/v2/satellites/{id}/recalibrate endpoint. The frontend team shows Vera that the "Recalibrate" button is hidden in the React UI whenever user.role !== "director".

Vera opens a terminal, copies a standard read-only observer session token, and runs curl -X POST https://portal.chronos.orbital/api/v2/satellites/SAT-09/recalibrate. The server returns 200 OK and queues the recalibration. Why? Because the frontend team placed the policy check on the wrong side of the trust boundary.

Hiding Recalibrate when user.role !== "director" does not lock POST /api/v2/satellites/{id}/recalibrate. An observer session token still gets 200 OK.
Client-side UX conveniences vs server-side security controls across the trust boundary
Design LayerWho Controls Execution?Appropriate RoleWhat Happens If Used for Security
Browser / Mobile UI (Client Side)The end user or attacker (via DevTools, Burp Suite, curl, or custom scripts)Fast ergonomic feedback, formatting hints, hiding irrelevant UI buttonsCompletely bypassed in one second by sending raw HTTP requests directly to the API
API Gateway / Edge ProxyMeridian Infrastructure (chronos.orbital)TLS termination, rate limiting, JWT signature verification, coarse route filteringStops unauthenticated flood traffic, but lacks fine-grained business object ownership context
Application Controller & Service LayerMeridian Backend RuntimeStrict schema validation, role & object-level authorization (BOLA defense), parameterized queriesAuthoritative enforcement point before any state change or database query executes

Where trust boundaries live in an application

A trust boundary is any line in a system architecture where execution or data moves from a lower-trust privilege level to a higher-trust privilege level. The most obvious trust boundary sits between the user’s client device and your HTTPS API listener. Even though TLS encrypts the channel in transit, TLS only guarantees that the attacker’s tampered HTTP request arrives at your server intact and confidential.

Additional trust boundaries exist inside your backend: between a public-facing web tier and an internal billing service, between an application server and a relational database parser, and between an AI orchestrator and the external web pages it retrieves.

The first trust boundary sits between the client device and the HTTPS API listener. More trust boundaries sit inside the backend.

Defending the boundary: AuthZ, BOLA/IDOR, and schema validation

Every time data crosses a trust boundary into a server handler, three checks must run in order before business logic executes. First, authenticate the session or token. Second, enforce both function-level and object-level authorization. Checking that a user is logged in is not enough: if tenant aero-labs requests GET /api/v2/telemetry/pass-8841, the server must verify in the database that pass-8841 actually belongs to aero-labs (preventing Broken Object Level Authorization / IDOR, OWASP API1).

Third, validate all input against a strict allowlist schema (types, lengths, numeric bounds, and allowed enum values) and use parameterized queries or structured APIs so user data can never be interpreted as executable code or SQL syntax.

Three checks run in order: authenticate the session or token, function-level and object-level authorization, then the allowlist schema. An ownership check stops aero-labs from reading another tenant's GET /api/v2/telemetry/pass-8841 (Broken Object Level Authorization / IDOR, OWASP API1).

Never trust client-supplied price, role, or tenant IDs

A subtle cousin of IDOR is mass assignment or trusting authoritative attributes from the request body. If a profile update endpoint accepts {"displayName": "Dax", "role": "admin", "organizationId": "org-1"} and blindly merges the JSON payload into the database record, any user can promote themselves or hop tenants. Authoritative identity and tenant scope must always be read from the server-verified session token, never from client-editable form fields or URL parameters.

Blind merge: any user can promote themselves or hop tenants. Identity and tenant scope come from the server-verified session token, not the request body.

CHECK YOUR JUDGMENT

A developer at Meridian Space & Robotics (chronos.orbital) builds an invoice download endpoint GET /api/v1/invoices?invoiceId=1042. To prevent customers from downloading other tenants’ invoices, the React frontend only renders links for invoice IDs belonging to the logged-in customer, and the form input disables typing custom IDs. Is this control sufficient?

NEXT FIELD LESSON

Data protection and resilience: why encryption is not a backup plan

↗

Find your next idea.

Tip: press / to open search. Escape closes this window.