Overview
The engagement runs in three layers. The binary is decompiled and reviewed for hardcoded secrets, weak cryptography, insecure storage and exported components. The running application is instrumented to bypass root and jailbreak detection, defeat certificate pinning, and rewrite client-side decisions. Then the backend is tested as the application’s API, which is usually where the critical findings are.
Client-side controls are treated as an obstacle, not a boundary. The question is never whether pinning can be bypassed; it is what the server does once it has been.
Engagement at a glance
- Platforms
- iOS (IPA) and Android (APK/AAB), native and cross-platform
- Typical duration
- 5 to 12 working days per platform
- Approach
- Static analysis, runtime instrumentation and backend API testing combined
- Standards
- OWASP MASVS and the OWASP Mobile Application Security Testing Guide
- Devices
- Testing performed on jailbroken/rooted hardware and emulators
- Deliverable
- Findings split by layer: binary, runtime, transport and backend
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Static analysis of decompiled source and resources
- Hardcoded credentials, API keys and cryptographic material
- Insecure local storage: keychain, keystore, shared preferences, SQLite, cache
- Certificate pinning and TLS validation bypass
- Root and jailbreak detection bypass
- Runtime instrumentation and method hooking (Frida, Objection)
- Exported activities, services, receivers and content providers
- Deep link and custom URL scheme abuse
- Inter-process communication and clipboard exposure
- Backend API testing from the mobile client’s perspective
- Biometric and local authentication bypass
- Third-party SDK and dependency review
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Secrets in the package | Decompiled classes, resources, assets, native libraries and build artefacts swept for keys and endpoints | Direct backend access using the application’s own credentials |
| Local storage | Keychain and keystore entries, databases, preference files, logs and caches read on a compromised device | Session tokens and personal data recoverable from a lost or shared device |
| Transport | Pinning implementation, TLS validation, fallback behaviour when pinning fails | Full traffic interception and modification |
| Client-side controls | Feature flags, entitlement checks, price and limit validation enforced only in the app | Paid tiers unlocked, limits bypassed against the live backend |
| Platform surface | Exported components, deep links, intents and URL schemes invoked by a malicious application | Unauthenticated actions triggered by another app on the device |
| Local authentication | Biometric prompt result trusted locally, PIN comparison in-process, hook resistance | Application unlocked without the user’s credential |
| Backend | Full API test using the mobile client’s tokens and endpoints | The same critical classes as an API engagement, reached through the app |
What we commonly find
The API key that was never meant to be public
A key extracted from the package that carries more privilege than the application needs: often a maps, storage or messaging key billed to you.
Server trusting a client-side decision
Subscription tier, price, distance and eligibility computed in the app and posted to the server as fact.
Session tokens outliving logout
The application clears local state; the server keeps honouring the token that was extracted an hour earlier.
Deep links that perform actions
A link scheme that, when opened by any installed application, carries out a state-changing request with the victim’s session.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Before a first public release on the App Store or Google Play.
- Ahead of an enterprise procurement review or a bank’s vendor assessment.
- After adding payments, biometric authentication or a new SDK.
- Annually, with a delta test after significant releases.
Questions
Do you need the source code?
No, testing is performed on the shipped package as an attacker would. Source access, if provided, adds a static review layer and speeds up root-cause analysis, so findings come with an exact file and line rather than a behavioural description.
Our app has certificate pinning and root detection. Is testing still useful?
Yes, and more so. Both are bypassed in the first hours of a professional engagement; their value is raising the cost for opportunistic attackers, not stopping a determined one. The engagement documents how each was bypassed and then tests what the server does once the protections are gone.
Do you test both platforms?
Both can be tested in one engagement. Where the applications share a backend, the API test is performed once and the platform-specific layers are tested separately, iOS and Android fail in different ways at the storage and IPC layers.
Can you test an app distributed only through MDM or TestFlight?
Yes. Provide the build through your distribution channel, or supply the IPA/APK directly. Enterprise-signed and internally distributed builds are routine.
How much does a mobile application penetration test cost?
Scope is driven by platform count, whether the backing API is in scope, and whether source code or only the built package is available. Testing one platform and its API is the common shape. A fixed quote follows a short scoping call.
Do you test against the OWASP MASVS?
Yes. Coverage follows the OWASP Mobile Application Security Verification Standard across storage, cryptography, authentication, network communication, platform interaction, code quality and resilience, with findings mapped to the relevant MASVS requirements alongside CVSS ratings.
What do you find most often in mobile apps?
Secrets in the package, controls enforced only on the client, and insecure local storage. Keys, tokens and endpoint URLs extracted from the binary are the most common; the most damaging is usually a rule the app enforces locally that the API never re-checks, because rewriting the client is trivial once you have it.
Do you test the backend API as part of a mobile engagement?
It is scoped explicitly rather than assumed, and we recommend including it. A mobile application ships the client to the attacker, so the real boundary is the API. Testing the app without the API tells you how the app behaves, not what an attacker can make the server do.
Can you test an app that uses biometric or device-bound authentication?
Yes. The question is whether the biometric check gates a local boolean or an actual server-side credential. Where it gates a boolean, the check is bypassable at runtime and the account is not protected by it. Testing covers the binding between the device, the key material and the session.