How a mobile app pentest is run: app, device and backend

The three surfaces a mobile app pentest tests

Most people picture a mobile app pentest as testing the app on the phone. The app is one of three surfaces, and rarely the one with the worst finding. The first is the application package: the code and configuration shipped to every device. The second is the device at rest, meaning what the app writes to storage, caches and logs while it runs. The third is the backend, the API the app calls for everything it cannot do alone. A mobile app pentest that examines one and glances at the other two reports a clean result the app has not earned.

Each surface fails in its own way. The package can carry a hard-coded key, a debug flag left switched on, or a permission the app never needed. The device can keep a session token in clear text or print an identifier to a log. The backend can authorise a token without checking who owns the record it hands back. A test scoped to the client alone would find the first, guess at the second, and miss the third entirely.

So the method treats the app and its server as one system. The figure below shows the three surfaces in the order an attacker meets them, from the binary in their hands to the data on a server they never touch directly.

How the engagement runs, from build to backend

The work runs in three phases: prepare, test, report. Preparation is not a formality. The tester needs devices they can inspect, a rooted Android handset or a jailbroken iOS device, with an intercepting proxy trusted on each. They also need a signed build of the app and a test account for every role the app supports. Test it as a single ordinary user and half its logic goes unreached.

Testing then takes each surface in turn. Static analysis reads the package before the app runs. Dynamic analysis watches the app on a prepared device and inspects what it writes and sends. Backend testing probes the API directly, with the app out of the way. The order can flex, and a finding on one surface often sends the tester back to another, but every surface is covered before the engagement closes. This is ordinary penetration testing discipline. It follows the phases NIST SP 800-115 sets out for a technical security test, applied to a client that happens to live on a phone.

Reporting comes last, and it is the part a regulator or a board reads. Each finding carries reproducible steps, evidence, a severity and a fix. A retest after remediation confirms the fix worked rather than moved the problem. That retest record is part of what makes the report defensible.

Static and dynamic analysis, and why one is not enough

Static analysis reads the app as a file. The tester unpacks and decompiles the package, then reads the code, the resources and the configuration the developer shipped. This turns up secrets compiled into the build, weak or home-made cryptography, debug flags, exported components and permissions the app requests but does not use. A static pass might find a line like `API_KEY = "AIza..."` in the package: a third-party key that should never have left the build server. None of this needs the app to run.

Dynamic analysis watches the app while it runs on a prepared device. It sees what static analysis cannot: the token written to storage in clear text, the response cached to disk, the request sent to the backend, the behaviour that only appears once a real user logs in. Neither pass replaces the other. A secret the app decrypts only at runtime is invisible on disk, and a flaw in how the app behaves is invisible in the code until you run it. Both passes are set out in the OWASP Mobile Application Security project, which publishes the verification standard and the testing guide the work follows. What the app leaves behind at rest is covered in insecure storage: what a mobile app leaves on the phone.

The table below sets the two side by side. A test that does one and skips the other reports a partial picture as a whole one.

The backend is in scope

The most damaging mobile findings usually sit on the server the app talks to, not in the app. An app is a client. It renders screens and sends requests, while the data and the rules that protect it live on the backend. If the backend accepts a request because the token is valid, without checking that the caller owns the record it returns, then changing an identifier in the request hands back another user's data. That is broken object level authorization, a server-side flaw the app was only hiding.

So the tester goes at the backend directly. They read the traffic between app and server on a controlled device, map the endpoints and parameters, and then probe the API as its own target through an API pentest. Where the app pins its certificate, that pin has to come off first, which is the subject of breaking certificate pinning to read a mobile app's traffic. A test that stops when a pinned app refuses the proxy has confirmed the pin works and tested nothing behind it.

Treat the app and its API as one system with two ends. A finding on the client points at the server, and a finding on the server explains what the client was exposing. Scope them separately and a real weakness can fall into the gap between two engagements that never compared notes.

What to have ready before day one

Missing inputs are the commonest reason a test starts slowly. A mobile test needs a signed build of the app, ideally one that runs against a test environment rather than production, so the tester can try destructive actions without touching real customers or real money. It needs a test account for each role the app supports. Authorization flaws only appear when one role reaches what another role owns, the same principle a web application pentest works through on the browser side.

It also needs devices the client has authorised for inspection, or an agreement that the tester supplies them, and a named contact who can reset accounts, unlock features and answer a question the same day. Decide in advance whether testing runs against staging or production. If production, agree what is off limits and how real transactions are avoided. Where the app and its backend are one part of a wider estate, a full VAPT programme scopes the client, the API and the infrastructure behind them together rather than as three separate jobs.

All of this is routine, and all of it is cheaper to settle before the engagement than during it. Hand over a working build on day one, with accounts that log in and a contact who answers, and the test spends its time finding flaws instead of waiting for access.

What a mobile app pentest means for regulated apps in the UAE

In the UAE, banks, government services and healthcare providers all reach their customers through mobile apps, and each sits under a regulator that expects the client, the device and the backend tested together rather than the server alone. A bank shipping a consumer app answers to the Central Bank of the UAE, whose framework treats customer data and authentication as controls that have to be evidenced, including on the mobile channel. A Dubai government entity, and any supplier building an app on its behalf, works to the Dubai Electronic Security Centre standards, which reach the app as much as the backend. Abu Dhabi healthcare providers fall under ADHICS, where personal health data cached on a device is in scope.

For a team in Dubai or Abu Dhabi, this is the practical reason the method covers three surfaces rather than one. A regulator can ask you to show that you tested the client and the data it leaves behind as well as the API, and a server-side review alone will not answer that. A free-zone entity building for the mainland market carries the same expectation as a mainland one, because the regulator follows the data and the customer rather than the licence address. Federally, the UAE Information Assurance Standards published through the national framework set the baseline the other regimes build on. Scope the mobile test across the app, the device and the backend, and the evidence is something an examiner in either emirate can read.

Frequently asked questions