What a Mobile Application Pentest Actually Finds

There is a version of mobile application security testing that is essentially a web application pentest conducted from a slightly unusual vantage point. The tester proxies traffic through Burp, pokes at API endpoints, tests for authentication bypasses and injection vulnerabilities, writes up a report that could have been generated from any browser. It is not useless. It is also not a mobile pentest.

Real mobile application security testing is a different discipline. It involves pulling apart the application binary, examining how data is stored on the device, looking at how the app communicates with the underlying OS, and finding the problems that exist specifically because this is software running on hardware a user controls - not hardware you control.

The findings are different. The severity hierarchy is different. And the vulnerabilities unique to mobile clients are the ones most organizations have tested for the least.

The Binary Is a Starting Point

Mobile application security testing typically begins before any network traffic is intercepted. Static analysis of the application binary - decompiling an Android APK or decrypting and analyzing an iOS IPA - surfaces things that never appear in network traffic because they are baked directly into the package.

Hardcoded API keys are the most common finding and the most consistently underestimated. Developers embed credentials for analytics platforms, cloud storage, payment processors, internal APIs, and third-party services directly in the application code. This happens because mobile apps need to authenticate to services at runtime, and the easy path is to put the credentials in the client. Those credentials ship to every device that downloads the app. They can be extracted in minutes by anyone with the binary and the right tooling.

Hardcoded secrets in a mobile app are not like secrets in internal code. The app is distributed publicly. Assuming credentials in the binary will remain private is a bet that no one with a decompiler and ten minutes of curiosity will ever try.

Data Storage on the Device

The device is not your environment. When a user installs an app, they own the hardware it runs on. On a rooted Android device or a jailbroken iOS device, an attacker can read files your application writes to local storage directly.

This matters because applications routinely store sensitive data locally. Authentication tokens in unencrypted SharedPreferences files. Cached API responses containing personal data written to SQLite databases without encryption. Sensitive user information in NSUserDefaults, which many developers treat as ephemeral but which persists across sessions and backups.

The typical severity argument is that exploiting local data storage requires physical access to the device or a rooted device, which limits realistic risk. This is partly true and often overstated. Enterprise mobile device management scenarios give attackers a path to access device storage without physical presence. Malicious applications on the same device can sometimes reach storage areas they should not. And the backup attack vector - where sensitive data in local storage ends up in unencrypted cloud backups - creates exposure that does not require device compromise at all.

Certificate Pinning and Why Testing It Matters

Most production mobile applications implement certificate pinning to prevent traffic interception: the app refuses to communicate with any server unless the server presents a certificate from a specific issuer or matching a specific public key. This is generally a good practice.

It is also routinely bypassed by mobile penetration testers, which is the point.

Testing certificate pinning bypass matters for two reasons. First, if a tester cannot intercept traffic, they cannot assess vulnerabilities in the API communication layer. Second, the test validates whether the pinning implementation is actually robust or whether it falls to a generic Frida script. Many pinning implementations are bypassed by off-the-shelf tooling, which means the protection is cosmetic rather than real.

If your certificate pinning survives a determined bypass attempt during a pentest, that is useful information. If it falls in fifteen minutes, that is also useful information, and more urgently actionable.

Deep Links and Intent Handling

Android and iOS both support deep links - URI schemes that allow external applications and web content to launch specific parts of your app. Deep link handling is an area where mobile security testing surfaces vulnerabilities that have no web equivalent.

Improperly validated deep links can allow an attacker to construct URLs that, when followed by a user, trigger actions inside the application that should require authentication or explicit user intent. Navigation to sensitive screens, pre-population of forms with attacker-controlled data, or triggering state changes the application assumes could only come from within an authenticated session.

Android's Intent system extends this further: applications can expose Activities and Services to other apps on the device, sometimes unintentionally. An exported Activity included for legitimate cross-app communication but with no authentication check is a standard finding in Android assessments and a real attack surface for malicious apps running alongside yours.

What Actually Drives Severity

The severity hierarchy in a mobile assessment looks different from a web assessment. SQL injection in an unauthenticated API endpoint is still critical. A hardcoded AWS key that can access production data is critical. But the vulnerabilities that mobile testing specifically surfaces - insecure local storage, bypassable certificate pinning, exposed deep link handlers - tend to land at medium severity by default, adjusted upward when chained with other findings.

The business-relevant question is: what does exploitation actually require, and who would do it? Sensitive data stored unencrypted on a device matters differently for a consumer banking app (where the threat model is the user's own compromised device) versus an enterprise HR app (where the threat model is a stolen work phone). Context drives severity as much as technical impact.

Where mobile assessments consistently deliver value is in finding things no scanner touches: credentials baked into a binary that ships to ten million users, a backup that silently exports sensitive data to unencrypted cloud storage, a deep link that lets an attacker preload a login form with a phishing destination. Those findings exist because someone treated the app as a package running on a device, not as an API behind a TLS connection.

That is what a mobile application pentest actually is.