A mobile application is a distributed system in a small package. The installed client stores data, invokes platform features, accepts links, and presents controls. Most important business decisions still happen in remote APIs and identity services.
Testing only the application package can miss backend authorization failures. Testing only the API can miss the device state, client assumptions, and entry points that make those failures reachable. The useful boundary is the complete workflow.
The client is observable and modifiable
Code and configuration delivered to a user-controlled device should not be treated as a secret enforcement layer. Interface restrictions, disabled buttons, hidden routes, local flags, and request construction can often be observed or changed by someone controlling the client.
That does not make client controls meaningless. Local protections can reduce data exposure and make abuse harder. It means the backend still needs to enforce the authorization, state, and integrity rules that protect other users or systems.
The OWASP Mobile Application Security Testing Guide covers both platform behavior and the remote authentication and authorization systems mobile applications commonly depend on. Its authentication guidance covers stateful and stateless sessions, OAuth-based flows, and the need to test logout behavior. See OWASP MASTG mobile authentication architectures.
Follow identity across the workflow
A mobile assessment should identify how the user moves through account creation, login, verification, recovery, logout, role changes, and account disablement.
Questions include:
- Where are access and refresh tokens stored?
- What local condition unlocks them?
- Does logout revoke server-side access or only clear the interface?
- Are invitation, reset, and verification tokens single-use and purpose-bound?
- Does a role change affect existing sessions?
- Can a disabled account continue to use an old token?
- Does a mobile client receive a broader scope than the web client?
The proof should compare controlled account states rather than infer risk from a token’s presence alone.
Map the device-to-service route
Start with normal use. Observe the hosts, endpoints, methods, headers, identifiers, and state transitions needed for important workflows. Then connect those requests to the user role and protected object they affect.
A role and object matrix helps expose inconsistent decisions:
| Action | Standard user | Manager | Support role |
|---|---|---|---|
| View own record | Allowed | Allowed | Context dependent |
| View another tenant | Denied | Denied | Explicitly scoped |
| Change account state | Limited | Policy dependent | Explicitly authorized |
| Export data | Own scope | Managed scope | Audited support path |
The exact matrix depends on the application. The point is to state the expected rule before changing identifiers, roles, methods, or sequence.
Local data needs context
Mobile clients may write tokens, personal data, files, database records, logs, notification content, or screenshots to device-managed storage. A useful finding needs to explain who can reach that data and under which device conditions.
For example, a value in an application sandbox has a different exposure model from a value written to shared storage, copied to a system log, displayed in the app switcher, or included in an unprotected backup. Device encryption and operating-system isolation also affect the conclusion.
Tool output is a lead, not a final status. OWASP’s MASTG tool guidance explicitly warns that tools can produce false positives and false negatives and that their output needs review. See OWASP MASTG testing tools.
Entry points can bypass the expected screen order
Deep links, universal links, custom URL schemes, notifications, exported Android components, iOS extensions, and web views can open application behavior outside the normal navigation path.
Testing asks whether:
- the link or intent is restricted to the intended application and destination;
- untrusted values cross into a web view, file handler, or privileged action;
- the user is re-authenticated when the action is sensitive;
- a stale or partially initialized application state changes the decision;
- the backend independently validates the requested action.
A client-side route that opens an administrative screen is not automatically a vulnerability. It becomes meaningful when the underlying action is also reachable without the required server-side authorization.
Mobile findings often become API findings
Suppose a mobile interface permits a user to edit only their display name. The request also contains an unrendered accountTier property. If the backend accepts a modified value, the root cause is not that the interface hid the field. The API trusted a property the caller was not authorized to set.
The report should connect both sides:
- how the request was discovered in the mobile workflow;
- which value or state was modified;
- which controlled role sent it;
- what the server should have enforced;
- what unauthorized result was demonstrated;
- whether equivalent web, legacy, or partner routes share the behavior.
Prepare both sides of the assessment
Useful inputs include authorized builds or store links, supported operating-system versions, controlled accounts for meaningful roles, API documentation when available, test data, identity-provider details, and clear production safeguards.
If certificate pinning, device enrollment, hardware-backed keys, or third-party authentication affects testing, identify that during scoping. Do not assume every control should be bypassed or every device state is authorized.
What the result should tell the team
A mobile security report should separate device-local exposure, platform integration, client-side assumptions, backend authorization, and third-party dependencies. Each finding should identify the affected build and environment and explain whether remediation belongs in the client, the API, the identity service, or more than one layer.
The goal is not to prove that a modified client exists. The goal is to determine whether a user-controlled client can cross a trust boundary the system was supposed to enforce.
See Mobile Application Security Testing, read the NASA mobile-to-web case study, or review API testing for real attack paths.