Mobile application penetration testing
Your app ships to devices you do not control, held by people who may not be your users. Anything the app knows, a determined attacker can read.
Why mobile is a different problem
A web application runs on your server. A mobile application runs on a device in someone else's pocket, and that person can be the attacker. They can decompile the package, read what is hardcoded in it, hook the running process and change what it sends. Every control you implemented on the client is negotiable.
That shifts where the testing effort goes. The interesting questions are rarely about the interface. They are about what the app stores, what it trusts, and whether the API behind it enforces anything the app assumes it does.
What we test
The package itself
Reverse engineering the IPA or APK for hardcoded secrets, API keys, endpoint URLs, debug flags and test credentials left in a production build. Hardcoded keys are among the most common findings we report and among the easiest to abuse at scale, because one extraction serves every attacker.
Data on the device
What is written to local storage, shared preferences, SQLite databases, the keychain and keystore, logs, screenshots and backups. Whether sensitive data survives logout, and whether it can be recovered on a rooted or jailbroken device or from an unencrypted backup.
Transport and pinning
Certificate validation, certificate pinning and whether it can be bypassed, cleartext traffic, and what the app does when the connection is intercepted. Plenty of apps pin correctly and then fail open on error.
The API behind the app
This is normally where the serious findings are. Authorisation is tested per object and per function rather than per screen, because the app hides a button while the API answers the request regardless. Broken object level authorisation remains the most reliably exploitable class of flaw in mobile back ends.
Platform integration
Deep links and custom URL schemes, exported activities and services, inter-process communication, WebView configuration, clipboard handling, biometric prompts, and how the app behaves on a device that is already compromised.
How we work
Testing is manual, on real devices and emulators, using instrumentation to watch the app while it runs rather than only reading its code. We test against the OWASP Mobile Application Security Verification Standard so coverage is documented against a recognised baseline rather than our own preferences, and findings are mapped to the Mobile Application Security Testing Guide so your developers can see the technique as well as the result.
We test the production build wherever possible. A debug build behaves differently, and a report on a build nobody ships is a report about a hypothetical application.
What you get
Findings with the proof attached: the extracted key, the intercepted request, the file read off the device. Each carries impact, reproduction steps and remediation advice written for the platform rather than in general terms. We retest fixes within the engagement window at no extra cost, and the report is written to stand up when a client, an insurer or an app store reviewer asks for it.
Common questions
Do you need our source code?
No. We test the way an attacker does, from the shipped package, and that is normally the more useful result. Source code access speeds the review up and widens coverage, so we take it where you can share it, but it is not a requirement.
Do you test iOS and Android separately?
Yes, because the findings differ. The same codebase produces different storage behaviour, different platform integration risks and different bypass techniques on each. Cross-platform frameworks such as React Native and Flutter add their own issues, particularly in how the JavaScript bundle or Dart snapshot is packaged.
Does the API get tested as part of this?
Yes. Testing a mobile app without its back end leaves out where most of the exploitable risk sits. Where the API is large or shared with a web application, we will usually scope it as its own piece of work so it gets the time it needs.
Does the app need to be live on the store?
No. We can test a pre-release build distributed through TestFlight, Firebase App Distribution or a direct install. Testing before launch is generally cheaper, because the fixes do not have to go back through app store review.
How long does a mobile test take?
A single-platform application with a modest API is typically three to five days. Two platforms plus a substantial API is usually seven to ten. We scope on the feature set and the API surface rather than the screen count.
Related
Free, no obligation
Understand your exposure
An attacker’s first move is not an attack, it is a look. So we look first, and send you what we find, worst first.
- Services and ports you did not know were open
- Security misconfigurations on anything public facing
- Known vulnerabilities already indexed by engines like Shodan
- Company credentials sitting in known breach data
The only question is: do you know where and how to look?
We reply within one business day. Prefer to talk first? 01902 288763 or info@solusec.co.uk.
Nothing is touched on your systems. It is all public and already indexed, just scattered. We pull it together, which is what an attacker does first.
Ready to talk?
Scoping conversations are free and there is no sales team to get past. Tell us what you're dealing with and we'll tell you honestly what you need.