They should treat the compiled application as the primary security artefact and test the APK or IPA directly. The key is to observe runtime behaviour, network calls, authentication flows, and data handling in the shipped build, then use source code only as supporting context rather than the main evidence base.
Test the packaged app, not the missing source
When source code visibility is limited, security testing should start from the compiled build because that is what users and attackers actually receive. For mobile apps, the APK or IPA exposes the real runtime surface: network traffic, local storage, app permissions, certificate handling, session behaviour, and how authentication and sensitive data handling work after compilation and obfuscation.
A source-aware review can still help, but it becomes supporting evidence rather than the primary test artifact. The practical question is whether the shipped app leaks secrets, trusts the wrong endpoints, stores data insecurely, or behaves differently under instrumentation, replay, or malformed inputs.
What runtime testing reveals that source review cannot
Compiled mobile apps often hide enough implementation detail to make source-centric reasoning incomplete. Runtime testing shows what the app actually does with credentials, tokens, cookies, certificates, and cached data, including whether those values persist longer than intended or are transmitted to unexpected services. It also exposes logic that appears safe in design but fails under real device conditions, rooted devices, emulators, or traffic interception.
That is especially important for mobile because many high-impact failures are visible only in the shipped package: hard-coded secrets, weak transport validation, verbose error messages, insecure WebView behaviour, and client-side trust in data that should be validated server-side. The test target is therefore not just the binary itself, but the full set of interactions the binary performs in its environment.
Useful analysis usually combines dynamic inspection, proxying, device log review, and behavioural testing. If an app cannot be safely instrumented, testers still have enough signal from traffic patterns, permissions, storage artifacts, and observable business logic to determine whether the design is resilient or whether the implementation is leaking trust.
How to structure the test plan around the build
A strong plan begins with what the compiled app proves under normal use, then moves into abuse cases. Start by mapping the login flow, API calls, local persistence, and sensitive user journeys such as onboarding, payment, profile changes, file upload, or account recovery. Those paths usually reveal the most about authorization, token handling, and whether the app depends on client-side checks.
Then test for differences between expected and actual behaviour. Look for endpoints that accept modified identifiers, tokens that survive logout, offline caches that retain sensitive objects, and transport controls that break when a proxy or custom certificate is introduced. A mobile app can appear well designed in review and still expose data because the build trusts its own client too much.
Where available, source code can still narrow the search. It is useful for confirming suspected code paths, understanding obfuscation, and identifying the origin of a network request or stored object. But the decisive evidence remains what the compiled app does when a tester interacts with it as an untrusted client.
Why this matters for defenders and app owners
Mobile app testing is most valuable when it approximates the attacker’s reality. Attackers do not need the source code if the compiled build reveals secrets, accepts manipulated requests, or leaks business data through APIs and storage. That is why runtime evidence is usually more operationally meaningful than static inspection alone, especially for third-party apps, regulated environments, and release pipelines that ship frequent mobile updates.
For teams that own the app, the test output should feed directly into secret rotation, transport hardening, session review, and client-side trust reduction. If the build exposes too much with too little friction, the issue is not cosmetic, it is an implementation and exposure problem that will persist until the shipped artefact changes.
Risk and Threat Considerations
Mobile apps are easy to distribute and hard to fully control once shipped, which makes the compiled build a frequent source of exposure. If testers only read source or only trust vendor descriptions, they can miss secrets embedded in the package, weak certificate checks, or data that is cached locally in ways that survive logout or device compromise.
Failure mechanism: An attacker or tester can reverse, instrument, or proxy the shipped app, then observe or alter network flows, storage, and authentication behaviour to find secrets, weak trust decisions, or exposed business logic.
Impact: The result can be credential theft, unauthorized API access, data leakage, account takeover, or a false sense of security because the published app behaves less securely than the reviewed design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service Security | Mobile apps expose API and auth behaviour through shipped builds. |
| V6 — Authentication | The question centers on runtime authentication flows in the shipped build. | |
| V14 — Data Protection | Runtime testing must check local storage and transmitted data handling. | |
| Recommendation — Test API requests, authorization checks, and sensitive flows in the compiled app. Verify login, session, and token handling in the compiled app. Inspect cached data, secrets, and storage protections in the released app. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Mobile apps often rely on exposed APIs whose auth must be tested dynamically. |
| API1 — Broken Object Level Authorization | Runtime tests should confirm object access cannot be changed by the client. | |
| Recommendation — Probe the app's API auth paths for token misuse and bypass conditions. Test whether modified identifiers or requests expose other users' data. | ||
Practitioner Guidance
What to prioritise: Focus first on the authentication flow, API traffic, and local storage, because those are the areas most likely to reveal whether the compiled app is protecting secrets and sessions correctly. If those three areas are weak, deeper reverse engineering usually adds confirmation rather than changing the conclusion.
What to verify: Confirm that the app does not retain sensitive tokens after logout, does not accept unauthorised identifier changes, and does not silently downgrade transport or certificate validation under interception. The key judgement is whether the build still behaves safely when the tester controls the device and network.
Practitioner takeaway: Treat source code as context, but treat the compiled mobile app as the security truth, because that is the version an attacker can actually exercise, instrument, and abuse.
Related resources from NHI Mgmt Group
- How should security teams test mobile apps built with low-code or no-code tools before release?
- How should security teams test AI-enabled mobile apps for prompt injection risk?
- Why do mobile apps need more than source-code-based security tools?
- How should security teams cover the gap between source code and the compiled mobile app?