The client is not the authority
A mobile interface may hide an action for a user without permission. That is useful for usability, but not a security boundary. The backend is responsible for checking whether an authenticated caller is permitted to perform an operation on a specific resource.
Modern mobile applications often make authenticated API requests using tokens or cookies. Identity answers who the caller is; authorization answers what that caller may do. Treating those as interchangeable creates risk.
An intentionally simple example
Suppose an API receives a request to view an invoice:
GET /api/invoices/1042
Authorization: Bearer <access-token>The backend must determine whether the authenticated account can access invoice 1042. It is not enough to check that the token is valid or that the mobile app normally displays only the caller’s invoice numbers.
In a training lab, create two synthetic accounts and two synthetic invoices. Request account A’s invoice from account B’s authenticated session. If the API denies the request under the intended access model, the tested boundary is working. If the API incorrectly returns protected information, the behaviour warrants investigation and remediation.
What should the server check?
- Authenticate the caller using the server’s established session or token validation process.
- Check the requested operation against the caller’s actual entitlements.
- Verify ownership, tenant membership or other object-level permissions on every protected resource.
- Protect create, read, update and delete paths—not only the endpoints visible in the mobile UI.
- Log failures carefully without exposing credentials, full tokens or sensitive records.
Research beyond changing identifiers
Changing an integer in a request is a common lab illustration, but robust research also asks how the system constructs resource identifiers, manages tenant context, caches authorization decisions and handles indirect references. For example, a background export job must enforce the same user-to-resource checks as the interactive API request that starts it.
A secure mobile experience depends on backend decisions the user cannot bypass simply by modifying a client request.
Fix the root cause
Centralize authorization where appropriate, test access rules with positive and negative cases, and explicitly define which roles or tenants may read or change each resource. Build regression tests for cross-account and cross-tenant requests using synthetic fixtures.
When assessing an application, report demonstrated impact rather than assuming every unusual API response is a confirmed data breach.
Research boundary
All scenarios here are fictional training examples. They do not allege an authorization flaw in any real service.