Mobile Application Security Testing
Assess mobile applications and the backend systems they depend on.
A mobile application ships to the device. Once it is installed, the binary, its storage and its network traffic are all in reach of whoever holds the phone — which changes what can safely be treated as trusted.
Most mobile risk is not in the app alone. It is in the relationship between the app and the API behind it: what the client is trusted to decide, what it stores locally, and what the backend accepts because it assumes the request came from the official app.
The application on the device is one part of the surface. The systems it talks to are the rest.
- DEVICEAndroid / iOSBinary, local storage, platform configuration
- TRANSPORTNetworkTransport security, certificate handling, interception resistance
- APIAPIAuthentication, authorization, request validation
- BACKENDBackendBusiness logic and service-side controls
- DATADataSensitive records and what the app is allowed to retrieve
Platforms, OS versions and device coverage are agreed per engagement.
Testing areas
How we test mobile applications
- 01STATICReview the package, configuration and what ships inside the build.
- 02STORAGEInspect what the application writes to the device at rest.
- 03TRAFFICObserve and work with the traffic between app and backend.
- 04RUNTIMEExamine behaviour while the application is running.
- 05BACKENDTest the API directly, across roles, independent of the client.
- 06REPORTFindings, evidence and remediation guidance across both layers.
Why mobile testing is not just app testing
Controls implemented in the client are visible to anyone who installs the app. A check that happens only on the device is a user experience feature, not a security boundary — the request can still be made without it.
So the useful question is rarely “can the app be tampered with”. It is what the backend does when a tampered or hand-crafted request arrives, and whether it re-checks everything the app was trusted to enforce.
Organizations this typically applies to.
Testing is scoped per engagement. Nothing here implies industry-specific certification or accreditation.
When Should a Mobile App Be Assessed?
A report your team can actually act on.
Exact deliverables and their format are confirmed during scoping.
What was assessed, what was found and what it means, written to be read by people who will not read the technical detail.
Each finding described with enough precision for an engineer to locate and understand it.
Reproduction detail and supporting evidence, so findings can be verified rather than taken on trust.
Severity considered against your environment, not only against a generic scoring table.
Practical direction on addressing each finding, including where a change belongs architecturally.
Verification that addressed findings no longer reproduce, within the agreed retest scope.
Adjacent parts of the attack surface.
Questions we get asked before an engagement.
Both are in scope as a service. Which platforms an engagement covers depends on what you ship and what you ask us to assess — the two builds often differ enough that findings are not identical across them.
No. Testing can be performed against the built application. Source access, when available, makes review faster and more complete, so it is worth discussing during scoping.
The API a mobile app depends on is normally included, because most impactful mobile findings resolve to a server-side control. The exact backend scope is agreed up front.
Device and OS coverage is agreed per engagement rather than fixed, since the relevant versions depend on what your user base actually runs and what your app supports.
Request a Mobile Application Assessment
Tell us which platforms you ship, what the app stores and which API it depends on, and we will scope from there.