Mobile app security assessment: what binary testing does not cover
Key takeaways
Standard mobile app security assessments miss backend API authentication failures in 60% of cases because testers scope to the app binary and never enumerate the server-side endpoints the app calls (Vulnox assessment data, 2024).
Certificate pinning is implemented correctly in fewer than 1 in 3 mobile apps that claim to use it — the remainder pin the leaf certificate without pinning the chain, which any attacker with a rogue intermediate CA can bypass.
Android SharedPreferences and iOS NSUserDefaults are not encrypted by default. Vulnox found plaintext API keys in these stores in 44% of assessed consumer-facing apps, including apps that had passed third-party security reviews.
IAST instruments the running app and produces findings that neither SAST nor DAST surfaces; the practical gap is largest for business logic flaws in multi-step transaction flows.
The highest-risk mobile app finding in Vulnox assessments is not a binary vulnerability — it is an API endpoint that enforces authentication on the web client but skips it when the request comes from the mobile app, because the two codepaths were built by different teams.
TL;DR
Mobile app security assessments that stay inside the binary miss the real attack surface. The exploitable findings in the environments Vulnox assesses are mostly server-side — unenforced authorization on mobile API endpoints, backend logic that assumes the client is trusted, and credential storage decisions made early in development that nobody revisited. The binary is the front door. The API is the building.
The app passed the review
A fintech startup in Singapore had their Android and iOS apps assessed before launch. The assessor checked OWASP Mobile Top 10, traffic interception, local storage, binary protections. The report came back with three medium findings and one high — a certificate pinning gap on an older Android build. They fixed the pinning, shipped the app, and considered the security review done. Eight months later, Vulnox assessed the same environment as part of a broader gap analysis. We pulled the API documentation the mobile team had shared internally, enumerated the endpoints, and found a transaction history endpoint that returned full account data for any user ID — no authorization check, just a valid session token from any account. The mobile app only requested your own account ID. Nothing in the binary was wrong. The API was not protecting itself because the original development assumption was that the only client would be the mobile app, and the mobile app would only ask for data it was supposed to see.
The original assessment never tested the API layer directly. It tested whether the app was asking the right questions. It did not test whether the server was enforcing the right answers.
Why binary-focused testing misses the actual attack surface
A mobile app is two systems. There is the client — the binary running on the device — and there is the server-side API it communicates with. Most mobile app security assessments concentrate on the client. They look at how the binary handles data at rest, whether TLS is configured correctly, whether the certificate chain is pinned, whether sensitive values appear in local storage or logs. These are real findings. They are also the less exploitable half of the attack surface in the majority of environments Vulnox assesses. The more consistent finding is that mobile-specific API endpoints — endpoints that exist because the mobile app needs them, built separately from the web backend, often by a different team — carry weaker authorization than their web equivalents. The web API was built with API gateway policies, JWT validation middleware, and a security review. The mobile API was built fast because the app needed to ship. The authorization logic is thinner or absent entirely for certain endpoints. An attacker who obtains a valid session token — through phishing, credential stuffing, or account takeover — can call those endpoints directly, without the mobile app, and the server has no mechanism to distinguish that traffic from a legitimate request.
Example
In a healthcare client assessment, Vulnox found a patient record retrieval endpoint that accepted any patient ID in the request parameter. The mobile app only passed the authenticated user''s own ID. The server accepted any ID a caller chose to supply. The clinical team''s assumption was that the app controlled what data was requested. That assumption was correct for every user running the legitimate app. It was not correct for anyone who knew the endpoint existed.
The mechanism survives because mobile API endpoints are typically not included in the web application''s API security test scope. They live on a different base path, sometimes a different subdomain, sometimes a different server entirely. If the test scope is defined as ''the mobile application,'' the tester instruments the app, proxies the traffic, and tests what they observe the app doing. Endpoints the app does not call during the test session are not tested. Endpoints that exist but are not surfaced in the app''s normal user flows are not discovered unless the tester independently enumerates the API — which requires either documentation access or active fuzzing of the endpoint structure.
What assessments of mobile environments actually surface
Assessment base: Vulnox mobile application assessments, 2023-2024
Authorization enforcement asymmetry between web and mobile APIs
Across Vulnox mobile app assessments, the most consistent finding was authorization logic that was stricter on web-facing endpoints than on the mobile-specific equivalents. In several cases, the mobile endpoint had been built to avoid the overhead of the web API''s middleware stack and had not inherited the authorization checks. The difference was not visible from the binary.
A mobile app security review that does not independently enumerate and test the server-side API endpoints misses the finding that is most likely to result in data exposure. The binary tells you what the app intends to do. It does not tell you whether the server enforces those intentions for callers who are not the app.
Certificate pinning implemented on the leaf, not the chain
In assessments of apps that had documented certificate pinning as a security control, Vulnox found that fewer than 1 in 3 had pinned the full certificate chain. The remainder pinned only the leaf certificate. An attacker operating a rogue intermediate CA — or a corporate proxy doing TLS inspection — can issue a valid leaf certificate for the target domain that the pinned app will accept, because the chain validation stops at the intermediate.
Certificate pinning is listed as a security control in many mobile app security reports. The implementation detail — what is pinned and how the validation is performed — determines whether it actually prevents traffic interception. Reporting ''certificate pinning: implemented'' without validating the chain behavior produces a false assurance.
Plaintext credential storage in platform-default data stores
Android SharedPreferences and iOS NSUserDefaults are the fastest paths to persistent local storage during development. They are not encrypted by default. In 44% of consumer-facing mobile apps assessed by Vulnox, API keys, session tokens, or in two cases full account credentials were readable in these stores without device compromise — accessible to any other app on a device with the appropriate backup or debugging access.
The finding survives not because developers do not know about encrypted storage alternatives. It survives because the default path is faster and the credential was put there early in development, before security requirements were documented, and was never revisited. Code review does not always catch it because the call looks like normal app initialization.
Third-party SDK network calls outside the app''s TLS configuration
Analytics, crash reporting, and advertising SDKs integrated into mobile apps frequently make their own network calls using their own TLS configuration — separate from the app''s certificate pinning implementation. In assessments where apps had strong pinning on their own API calls, Vulnox observed third-party SDK traffic that bypassed the pinning entirely because the SDK managed its own connection stack. Data passed to these SDKs — device identifiers, session metadata, in some cases user behavioral data — left the app without the protections the app''s own networking layer applied.
Third-party SDK data flows are outside the scope of most mobile app security assessments. The SDK is a black box. Its network behavior is not documented. The data it transmits is not inventoried. This is an unmonitored data exfiltration path that exists in the majority of consumer apps.
The control that creates the gap it was designed to close
Common belief
Implementing certificate pinning significantly reduces the risk of traffic interception for mobile apps handling sensitive data.
What we found
In a payments app assessment, the client had invested in pinning implementation and documented it as a compensating control for a deferred backend authentication issue. Vulnox bypassed the pinning in 11 minutes using a standard Frida script and confirmed the backend authentication issue was exploitable without any binary modification. The compensating control was not compensating for anything.
Pinning raises the cost of interception for opportunistic attackers. It does not raise the cost for anyone with time to instrument the app using Frida or a similar dynamic analysis framework. In assessments of apps with pinning in place, Vulnox bypassed it in under 15 minutes using publicly available Frida scripts in the majority of cases. The pinning implementation that actually resists bypass requires root/jailbreak detection, Frida detection, and integrity checking of the pinning logic itself — none of which were present in any assessed app that relied on pinning as a primary control. The counterintuitive result is that a team that implements pinning and considers the traffic interception risk addressed has created a false security baseline. They have done something. The something does not match the assurance they believe they have obtained.
What teams say before the assessment, and what the assessment finds
We use HTTPS everywhere. Our traffic is encrypted. Network interception is not a realistic risk for us.
Root cause:TLS encrypts the channel. It does not validate the endpoint. An app that does not pin certificates, or pins them incorrectly, will complete a TLS handshake with a proxy that the user did not authorize. The traffic is encrypted between the app and the proxy. The proxy reads it in plaintext. The encryption claim is technically accurate and operationally misleading at the same time.
We had a security assessment done before launch. The report was clean.
Root cause:Pre-launch assessments are scoped to what exists at launch. The API surface grows after launch. New endpoints are added. Features are shipped under deadline pressure. The security review does not update automatically. An assessment that was clean at launch describes an app that no longer exists.
Our backend is secured. The mobile app is just a client.
Root cause:The mobile-specific API endpoints are usually not part of the backend security review. They live in a different codebase, were built to a different timeline, and are assumed to be protected because the app controls what it sends. That assumption does not hold for callers who are not the app.
The attack surface that mobile assessments do not reach
Deep link handling
Android and iOS both support URL schemes and universal links that allow external sources to trigger app behavior. Malformed deep link parameters that reach activity or view controller code without sanitization produce injection conditions that are functionally equivalent to web-based parameter injection. This is outside the scope of most automated mobile scanners. It requires manual testing of the link handling logic for every registered scheme and path pattern the app accepts.
WebView content loading
Hybrid apps and apps that render web content in native WebViews inherit web vulnerabilities in a native context. JavaScript bridges that expose native functionality to WebView content — file system access, camera, contacts — are an escalation path if the WebView loads content from an untrusted source or if the allowed origin list is misconfigured. The finding is not in the binary and not in the web content independently. It is in the interface between them.
Backend logic assumptions about the client
Server-side code written with the assumption that the only caller is the mobile app frequently skips input validation on parameters that the app controls. If the app always sends a positive integer for a quantity field, the server may not validate that the field is positive. A caller who is not the app sends a negative value. The server processes a refund instead of a charge. This class of finding is not visible in the binary, not visible in the server-side code review without knowing what the app is expected to send, and not visible in automated scanning.
Backup and export behavior on iOS
Files stored in the iOS app sandbox are included in iCloud and local iTunes backups by default unless the app explicitly excludes them. Sensitive data written to the Documents directory — which many developers use because it is the obvious writable location — is backed up and extractable from a backup without device access. This is a data-at-rest exposure that does not require compromising the device.
Where mobile app attack surface is going
Within two years, third-party SDK data collection in mobile apps will become a primary regulatory enforcement target under GDPR and equivalent frameworks, and the organizations most exposed will be those that conducted mobile security assessments that never inventoried SDK network behavior.
Regulators have begun requiring data flow maps that account for third-party processing. Most mobile app security assessments do not produce SDK traffic inventories. The gap between what organizations believe their apps transmit and what SDK telemetry actually sends is large and largely undocumented. The first enforcement actions that cite SDK traffic as undisclosed processing will surface compliance programs that assumed security assessments covered data flow documentation. They do not.
Confidence: highGDPR enforcement decisions citing third-party SDK data flows as undisclosed processing, published by a supervisory authority before end of 2026.AI-assisted binary analysis will reduce the time required to identify obfuscated credential storage in mobile app binaries from hours to minutes by 2026, making the current reliance on obfuscation as a defense against hardcoded secret extraction obsolete faster than development teams will update their threat models.
Static analysis tools with LLM-assisted decompilation are already shortening the time to meaningful reverse engineering output. The apps that rely on string obfuscation to protect embedded API keys are operating on an assumption about attacker time investment that is becoming less accurate each quarter.
Confidence: mediumPublic release of a widely adopted tool that reduces hardcoded secret extraction from obfuscated Android or iOS binaries to under five minutes of analysis time, before end of 2026.
The assessment scope decision that determines whether the engagement is useful
A mobile app security assessment scoped to the binary is a compliance exercise dressed as a security exercise. The binary findings are real. They are also the findings an attacker can work around. The server-side API — specifically the mobile-specific endpoints built alongside the app rather than inherited from the web platform — is where the exploitable access is. I have seen this pattern in enough assessments that I would argue a mobile app security engagement that does not include independent API enumeration and authorization testing on the mobile-specific endpoint surface should be labeled as a ''mobile binary review,'' not a security assessment. The distinction matters because teams use the assessment output to make resource allocation decisions. A clean binary review does not mean the app is secure. It means the binary is not the problem.
Counterargument
The reasonable counterargument is that API security testing is a separate discipline with its own scope, methodology, and time budget, and that folding it into a mobile assessment inflates the cost and timeline in ways that smaller teams cannot absorb. That constraint is real. It does not change what the assessment is measuring when API testing is excluded. Teams should know what they are buying.
One thing to do this week
Pull the list of API endpoints your mobile app calls. Not from the binary analysis — from the server logs or API gateway, filtered to requests that come from your mobile app''s user agent. Compare that list against what your last security assessment tested. Count the endpoints on the first list that do not appear on the second. That number is the untested API surface your mobile app depends on. If it is more than zero, start there.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessment servicesNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionOWASP Testing Methodologies
OWASP testing methodologiesGDPR Compliance Guidelines
GDPR compliance guidelines
Frequently Asked Questions
What does a mobile app security assessment typically miss?
Most mobile assessments scope to the binary and miss the mobile-specific API layer. Vulnox assessments consistently find authorization failures on server-side endpoints that the mobile app calls but that were never tested — because the assessment scope was defined as the app binary, not the full API surface it depends on.
How do attackers bypass certificate pinning in mobile apps?
Frida-based instrumentation bypasses most certificate pinning implementations in under 15 minutes using publicly available scripts. Pinning that resists bypass requires root detection, Frida detection, and integrity checking of the pinning logic itself. Fewer than 1 in 3 apps assessed by Vulnox had all three.
Why is Android SharedPreferences a security risk for mobile apps?
SharedPreferences is not encrypted by default. Vulnox found plaintext API keys and session tokens in SharedPreferences in 44% of assessed consumer-facing apps — including apps that had passed third-party security reviews. The data is accessible to other apps with appropriate backup or debugging access without requiring device compromise.
What is the most exploitable finding in mobile app security assessments?
In Vulnox assessments, the most consistently exploitable finding is a backend API endpoint that enforces authorization for web clients but skips it for requests from the mobile app — because the mobile endpoint was built separately, on a faster timeline, without inheriting the web platform authorization middleware.
Do third-party SDKs in mobile apps create security risks?
Yes. Analytics, crash reporting, and advertising SDKs make their own network calls using their own TLS configuration, separate from the app''s certificate pinning. Data passed to these SDKs — device identifiers, session metadata, behavioral data — leaves the app without the protections the app''s own networking layer applies. This is outside the scope of most mobile security assessments.
How often should mobile apps undergo security assessments?
A pre-launch review describes an app that will no longer exist after the first feature release. Any significant API surface expansion — new endpoints, new integrations, new data flows — warrants reassessment of the affected scope. A single annual assessment of a live, actively developed app leaves months of untested attack surface.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.