Core Capability
Mobile Application Penetration Testing
Native iOS and Android testing that goes well past the store build — binary analysis, on-device storage, transport security, and the backend API your app depends on.
- Testing mapped to the OWASP MASVS and Mobile Security Testing Guide
- Real devices, including rooted and jailbroken handsets
- The backend API is in scope, not treated as somebody else's problem
What we test in a mobile application
A mobile app ships to the attacker's device. They control the operating system, the network path and the runtime, which invalidates assumptions that hold perfectly well on a server. Our testing starts from that position rather than treating the handset as trusted.
The binary and the runtime
- Reverse engineering of the application binary to recover logic, endpoints and embedded secrets
- Hardcoded API keys, credentials and cryptographic material inside the package
- Runtime manipulation: method hooking, certificate unpinning and tamper detection bypasses
- Effectiveness of root and jailbreak detection, obfuscation and anti-debugging controls
Data at rest on the device
- Insecure use of local databases, shared preferences, plists and cache directories
- Keychain and Keystore configuration, including accessibility and hardware backing
- Sensitive data leaking into logs, crash reports, clipboard and screenshot snapshots
- Backup exposure through device sync and platform backup mechanisms
Data in transit
- TLS configuration, certificate validation and certificate pinning implementation
- Interception resistance under an active man-in-the-middle position
- Fallback behaviour when pinning fails or the network is hostile
The API behind the app
Most serious mobile findings are not in the app at all — they are in the API the app talks to, which was built assuming only the app would ever call it. We test authorisation on every endpoint the binary reveals, including endpoints the interface never exercises, because an attacker calls them directly.
Platform coverage
- Native iOS applications written in Swift and Objective-C
- Native Android applications written in Kotlin and Java
- Cross-platform builds produced with React Native and Flutter
- Third-party SDK behaviour, including analytics and advertising libraries that exfiltrate more than expected
What you receive
- Findings for the app and the API it depends on, in a single report
- Reproducible proof of concept for each issue, with the tooling and device configuration used
- Patch-level guidance for your mobile engineers and your backend team separately
- An inventory of secrets and endpoints recoverable from the shipped binary
- Evidence mapped to the compliance framework you are working towards
How iOS and Android fail differently
Treating the two platforms as one target misses findings, because their storage, backup and inter-application models are genuinely different. Where both builds are in production, both need testing.
iOS
Keychain accessibility attributes are the recurring failure: a credential stored with a protection class that survives device lock, or synchronises to iCloud, when it should do neither. We also check app transport security exceptions, data written outside protected containers, pasteboard exposure, screenshots retained when the app is backgrounded, and URL scheme handlers that accept input from any other installed application.
Android
Exported components are the equivalent: activities, services, broadcast receivers and content providers reachable by any other installed app, frequently without the caller checks the developer assumed were implicit. We also test keystore usage, backup flags that place private data into user-accessible backups, WebView configuration including JavaScript bridges, and deep link validation.
Why mobile findings take longer to close
A web fix ships when you deploy. A mobile fix ships when the store approves it and then only reaches users who update, which means a serious client-side finding leaves you exposed on old versions for as long as those versions keep working.
This changes what good remediation looks like. Where a finding can be mitigated server-side we say so explicitly, because a server change protects every installed version immediately. Where it genuinely requires a client fix, the practical answer usually involves a forced-upgrade floor, and knowing that early is better than discovering it during an incident.
Standards we test against
Coverage follows the OWASP Mobile Application Security Verification Standard, which is considerably more specific than the web Top 10 and maps cleanly onto the platform behaviours above. Where the backend is in scope, API findings are reported against the OWASP API Security Top 10 as well, so the report speaks the language your auditor and your developers already use.
Common questions
Do you need the source code or just the app build?
A build is enough to start. Give us an IPA or APK and test accounts and we can perform a full assessment. Source code access shortens the time needed to confirm certain findings and lets us give more precise patch guidance, so we will use it when you can share it.
Do you test on emulators or real devices?
Real devices, including rooted and jailbroken handsets, because several controls behave differently outside an emulator. Emulators are used only where a specific test case needs an instrumented environment.
What about third-party SDKs we do not control?
They are in scope for observation. We report what an SDK collects and transmits and where that creates exposure for you, since responsibility for that data still sits with you even when the code does not.
Do you test the backend APIs as well as the app?
The app is a client, and most serious mobile findings are on the server it talks to. Testing the binary without testing the API behind it covers local storage and reverse engineering while leaving authorisation, object-level access and business logic untested. We scope both together unless you have a specific reason to separate them.
Does certificate pinning stop you from testing?
No, and if it did the test would be nearly worthless, because an attacker with a rooted device is not stopped either. We bypass pinning to inspect traffic, then report on how robust the pinning implementation is as a separate finding. Pinning raises the cost of casual interception; it is not a boundary that keeps a determined analyst out.
What do you look for in local data storage?
Credentials, tokens, personal data and cached responses written where another app or a backup can reach them, which in practice means preference files, unencrypted databases, logs, screenshots retained on backgrounding, and anything placed outside the platform's protected keystore. We also check whether data survives logout, which it frequently does.
Do you test both iOS and Android, or can we test one?
You can test one, but the platforms fail differently — keychain and keystore behaviour, backup semantics, inter-app communication and reverse engineering difficulty all differ. If both are in production, testing both is the honest scope. If budget forces a choice, we would usually start with Android because analysis is easier for an attacker.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.