Mobile app VAPT
The Android and iOS build you ship, and the API it talks to.
A mobile assessment starts from the APK or IPA you actually publish, not from the source repository. We look at what the app stores on the device, what it sends, and what the backend accepts when the app is taken out of the picture. The API behind a mobile app is often tested less than the web one, because people assume only the app can call it.
What we test
- Local data: tokens, personal data and keys in preferences, databases, logs and backups
- Network: TLS, certificate pinning and what happens when it is bypassed
- Authentication and session handling between the app and its API
- Exported components, deep links and intents that other apps can trigger
- Secrets and endpoints embedded in the build, debug flags left on in release
- The backend API, tested directly with the same depth as the web and API service
What do you get at the end?
- A written report with severity, affected screen or endpoint, evidence and fix for each finding
- Findings mapped to OWASP MASVS control groups
- A retest of the fixed build
How does the engagement run?
Scope and written authorization first, then testing inside the agreed window, the report, and a retest of what you fix. The steps are the same for every service and are set out on the approach page.
Frequently asked questions
Which builds do you need?
The release build you plan to ship (or a release candidate) for each platform in scope, plus test accounts. A debug build is useful for the API work but is not a substitute.
Do you test both Android and iOS?
We test the platforms you put in scope. Each platform is a separate build with its own storage, permissions and network code, so a finding on one is checked on the other rather than assumed. The shared backend API is tested once and reported once.
Do you test the backend API too?
Yes. The API behind a mobile app is often the larger risk, because teams assume only their app can call it. We call it directly, outside the app, with the same depth as the web and API service.
Tell us what you want tested.
A short call, then a signed scope. No testing before that.