Mobile Application Penetration Testing

Usually yes, because a shared codebase does not give you shared security behaviour. Cross-platform frameworks still compile down to a native binary on each side, and the things an attacker cares about are decided by the platform rather than by your shared logic: where credentials come to rest, whether the keystore or the keychain is used and how it is configured, what happens to the screen when the app is backgrounded, what a neighbouring app on the same device is permitted to read, and which debugging and backup flags the build carries. That is why our static and dynamic phases run separately per platform and the findings are written per platform, so each team fixes what is theirs. If budget forces a sequence, start with the platform carrying more of your users or more of your sensitive flows. Whether we test one platform or both is also one of the things that moves you within the indicative range on this page.

More often than not, the backend. A flaw that lives only on the handset is bounded by that handset: someone who already controls the device learns something about their own account. A flaw in the API behind the app is unbounded, because the same request can be replayed with another customer's identifier from anywhere. Mobile apps make this worse in a specific way. Teams put the authorisation decision in the screen rather than the endpoint, hide an administrative function behind a feature flag the client evaluates, or trust a price, a role or a user identifier the app sends up. Pull the app apart and those endpoints are simply listed for you. That is why the engagement has a phase dedicated to testing the backend the app calls and to chaining device-side and server-side flaws into one impact statement. If the API serves more than this app, our separate API penetration testing service is the fuller scope.

Four things: installable builds for each platform in scope, working test accounts, the backend endpoints those builds point at, and a named contact who can answer questions during the test. For the builds, send us what you ship rather than a debug variant, since debug flags and logging change the answer. For accounts, give us at least two per role so we can test one user against another, and create them fresh rather than handing over a real customer's login. Tell us in advance about anything that will block installation on our instrumented devices, such as device attestation, an MDM wrapper or an enterprise distribution profile. Source code is optional. We test from the compiled app alone, which is where an attacker starts, and source makes the static phase deeper and faster rather than possible. These are agreed in the scoping phase and written into the Rules of Engagement before anyone touches the app.

It tells you something precise: what an attacker reaches once they hold the device, which is the situation after a phone is lost, sold, resold or infected. A rooted or jailbroken handset is the instrument, not the threat model. We use it to read what the app wrote to disk, to watch the traffic it thought was protected, and to reach the code paths a stock device hides, then we report the underlying weakness rather than the fact that we rooted a phone. That distinction matters when you read the report. A bypassed root check or a defeated pinning implementation is not in itself the damage; it is the door, and the finding is whatever we got through it, such as a token in plain storage or an endpoint that never checks who is asking. We say plainly which of your protections held and which did not, so you can judge how much delay they really buy.

No, and it is worth separating the two. Store review checks policy, declared permissions and privacy disclosures; it is not a security assessment, and our report is not an approval. What the engagement does give you is evidence for the parts of that submission you have to declare honestly. The dynamic phase records what the app actually sends, to which hosts and over what transport, which is the same question a data safety form or a privacy label asks, and the static phase surfaces permissions and capabilities the build requests but never exercises. Where personal data is involved, that evidence also supports the notice and purpose obligations under the DPDP Act. Plan the sequence backwards from your submission date: scope early, leave room for the fix cycle, and keep the retest before you ship, so the version that goes to the store is the version whose fixes we confirmed.