A mobile app is a copy of your software that you hand to every user, including the ones who want to take it apart. Anyone can download your Android or iOS app, unpack it, read its code, watch its network traffic and run it on a rooted or jailbroken phone. A mobile penetration test does exactly that, under controlled conditions, so you find the weaknesses first.

What a mobile pentest covers

We test against the OWASP Mobile Application Security Verification Standard (MASVS) and use the OWASP Mobile Application Security Testing Guide (MASTG) as our method. In practice that means four areas:

  • The app package: what's inside the APK or IPA, such as hard-coded API keys, secrets, debug settings and leftover test endpoints.
  • Data on the device: what the app stores in local files, databases, logs, caches and shared preferences, and whether it's protected.
  • Network traffic: whether every connection uses TLS properly, and whether the app can be tricked into talking to an attacker's server.
  • The backend API: usually where the most serious issues are. The app is only the front door; the API behind it holds the data.

Our approach

1. Static analysis

We decompile the app and review the code and configuration without running it. On Android that includes the manifest: exported activities, services and content providers that other apps could reach, backup settings and network security configuration. On iOS we look at the Info.plist, App Transport Security exceptions, URL schemes and entitlements.

2. Dynamic analysis

We run the app on test devices, including rooted and jailbroken ones, and observe it while it works. We intercept and modify its traffic, inspect what it writes to storage, and use instrumentation tools to see how it behaves at runtime: for example, whether security checks can be switched off or bypassed.

3. API testing

Every request the app sends is replayed and modified. Can one user read another user's data by changing an ID? Does the server trust values it should check itself, like prices, roles or account numbers? Do tokens expire, and are they tied to the right user?

Issues we find most often

  1. Secrets in the app package. API keys, cloud storage credentials or third-party tokens compiled into the app. Anything shipped in the app should be treated as public.
  2. Sensitive data stored in plain text. Session tokens, personal data or cached API responses in unprotected files instead of the Android Keystore or iOS Keychain.
  3. Broken access control in the API. The same IDOR problem we see in web apps, often worse because teams assume nobody will look at mobile traffic.
  4. Security decisions made in the app. Checks for premium features, transaction limits or user roles done on the device, where they can be patched out, rather than on the server.
  5. Weak transport security. Disabled certificate validation left over from development, or cleartext traffic allowed to some domains.
  6. Exported components. Android activities or content providers that other apps on the phone can open or query without permission.

Root detection and certificate pinning help, but they're not a fix. They slow attackers down. A determined tester bypasses them in minutes, so the real protection has to be on the server: authorisation checks, server-side validation and short-lived tokens.

What you get

A report with every finding mapped to MASVS, the evidence and steps to reproduce it, a severity rating, and fixes your Android, iOS and backend developers can act on. Once you've fixed the issues, we retest them for free.

Planning a release or a security review from a customer? Request a quote for mobile app testing.