Mobile App Testing
Quoted on scope, fixed price. Includes the Vexil platform and a hand-verified retest.
Teams who have had us test their systems
- Selip & Stylianou, LLP
What this covers
Your mobile app handles sensitive user data, processes payments, and talks to your backend APIs. It also lives on an untrusted device that anyone can jailbreak, decompile, or proxy-intercept. We test iOS and Android apps against the OWASP Mobile Application Security Verification Standard (MASVS) at both L1 (standard) and L2 (defense-in-depth) levels. Our testing combines static binary analysis (MobSF, jadx, Ghidra), dynamic runtime instrumentation (Frida, Objection), and API traffic interception through Burp Suite Pro. You get a per-platform findings report with proof-of-concept screenshots, a shared API backend assessment, and fix recommendations written for mobile developers - Android in Kotlin/Java terms, iOS in Swift/Objective-C terms.
- Launch on App Store and Google Play without security rejections
- Protect user data with verified encryption and storage practices
- Pass enterprise client security reviews with a professional audit report
- Catch the mistakes every mobile team makes before they reach production
Scope
What gets tested
Ten areas, agreed on the scoping call and written into the rules of engagement before anything starts.
iOS Application Testing
IPA analysis, Keychain audit, plist inspection, biometric bypass (Face ID/Touch ID), ATS validation, jailbreak detection.
Android Application Testing
APK decompilation (jadx, apktool), manifest analysis, intent spoofing, content provider leaks, WebView security, root detection bypass.
Local Data Storage
SQLite, Realm, CoreData, SharedPreferences, internal/external storage, temp files, cached data leakage.
Network Communication
Certificate pinning bypass via Frida/Objection, MITM, protocol buffer analysis, WebSocket security, SDK traffic audit.
Authentication & Authorization
Biometric auth bypass, OAuth2 flows, session token handling, deep-link hijacking, custom URL scheme exploitation.
Code Hardening (MASVS L2)
Reverse engineering resistance, code obfuscation, anti-tampering mechanisms, root/jailbreak detection strength.
API Backend Testing
Backend APIs tested for BOLA/IDOR, broken auth, injection, rate limiting, and mass assignment.
Business Logic & Race Conditions
Concurrent request abuse, transaction replay, workflow bypass in mobile-specific flows.
OWASP MASVS L1 & L2
Standard (L1) and defense-in-depth (L2) verification aligned to Mobile Application Security Verification Standard.
App Store Readiness
Apple and Google developer security guideline compliance verification before submission.
Why a scan is not a test
What a scanner misses here
For part of it. But a scan reads the binary. It cannot drive the app, defeat pinning, and watch what the backend still accepts once the client has stopped enforcing anything.
Automated app scan
Finds what is there
- Hardcoded strings and keys in the binary
- Known CVEs in bundled libraries
- Debuggable and backup flags left on
- Missing certificate pinning
- Outdated SDK versions
Fast, and worth running.
Tester
Finds what is broken
- Session tokens still on the device after logout
- A biometric prompt passed without unlocking anything
- Pinning defeated so traffic can be rewritten
- An exported screen that opens a paid feature free
- A limit the app enforces and the backend does not
This is where the real risk is.
We run both, in that order. Tool output is kept separate from what a tester wrote, so you always know which is which.
Book a Free ConsultationMethodology
How the work is done
Repeatable, documented, and tracked as coverage inside the platform so you can see what has been looked at.
- 01
App Recon
Receive IPA/APK or TestFlight/Play Store link. Map permissions, third-party SDKs, and API endpoints. Review architecture overview with your mobile team.
- 02
Static Analysis
Decompile and analyze binary for hardcoded secrets, insecure configurations, vulnerable libraries, and exportable components.
- 03
Dynamic Testing
Runtime instrumentation with Frida/Objection. Intercept and modify API traffic. Test jailbroken/rooted device behavior.
- 04
Report & Re-test
Findings organized by platform (iOS/Android) and shared backend. Fix guidance in Kotlin/Swift. Retest included with every engagement.
Why it matters
What you get out of it
MASVS L1 & L2 Coverage
Standard security (L1) plus defense-in-depth (L2) - including anti-reversing, biometric auth bypass, and tampering detection testing.
Static + Dynamic Analysis
Binary decompilation, hardcoded secrets scanning, insecure library detection, plus runtime instrumentation with Frida to bypass client-side checks.
API Backend Testing Included
Your mobile app talks to APIs - we test those too. Certificate pinning, token handling, BOLA/IDOR, and rate limiting are all in scope.
Local Storage Deep-Dive
Keychain/Keystore usage, SQLite/CoreData/Realm inspection, shared preferences audit, and temp-file analysis - we find where your app leaks data.
Platform-Specific Guidance
Fix recommendations written in your stack - Kotlin for Android, Swift for iOS, with code-level guidance your mobile devs can implement directly.
App Store Readiness
We check against both Apple and Google developer security guidelines so you don't get rejected or flagged post-launch.
What you receive
Delivered in the platform as the work happens, and exportable as a document whenever you need one.
- Per-platform findings report - iOS and Android, each with proof-of-concept screenshots
- Shared API assessment - vulnerabilities in the backend both apps talk to
- Static analysis report - hardcoded secrets, vulnerable libraries, code-level issues
- Data storage audit - where your app stores sensitive data and how to lock it down
- Video walkthrough - live demo of every critical finding with Frida/reverse-engineering demo
- Re-test report - confirmation after fixes
Standards we test against
Coverage is tracked against these inside the platform, so “what did you actually check” has an answer.
- OWASP MASVS
- OWASP MASTG
- NIST SP 800-163
- PCI-DSS
- GDPR (mobile)
- ISO 27001
The anatomy of a finding
This is one finding.
Not a report. One finding, with every field it carries and why each field is there. Yours will look like this.
Vexil · Finding
Published- Titlewhat it is, in your engineers’ words
The session token stays readable on the device after logout.
- Affected assetwhere it is stored, not “the app”
Written on login, never cleared.
- iOS · NSUserDefaults
- Android · SharedPreferences
- Severitycomputed from the vector, never chosen by hand
- high
- CVSS 3.1 · 7.7
- AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
- CWE-312
- Evidencethe request, the response and screenshots, attached to the finding
After signing out, the stored token was replayed against the API and returned the account.
- GET /v1/account → 200
- Impactwhat it costs you, not what the CVE says
A shared, lost or backed-up device hands over the account. Logging out does not end the session, which is the one thing a user believes it does.
- Remediationfor your stack, not “apply vendor patches”
Hold the token in the Keychain or Keystore, and revoke it server-side on logout so a copied value is worthless.
- Retesta tester’s verdict, not your self-assessment
Retest passed. Verified by hand, recorded with the date and the tester.
This is the format, not a client’s work - it is written against the demonstration environment we run for the purpose, and a real finding also carries screenshots of the issue alongside the request and response. We don’t publish client findings, redacted or otherwise. If you want to see a real one, email us and we’ll send a redacted sample.
Pricing
What changes the price
Every engagement is quoted on scope rather than hours. These are the four things that move it, and they are what we work through on the call.
Platforms
iOS, Android or both
App size
Screens and features
Backend
Shared API in scope or not
Hardening
Pinning, root and jailbreak checks
Delivered on the Vexil platform
iOS and Android findings sit in one place with the backend issues they depend on, so a platform team can see which of them are theirs and which are the API’s.
See the platformFAQ
Questions about mobile app testing
Do you need source code, or can you test from the App Store / Play Store?
We can test from either. Testing from the store (black-box) simulates a real attacker. With source code (white-box), we find deeper issues like hardcoded secrets and logic flaws. A TestFlight or Play Store beta build is the usual starting point, and the one we recommend. If you share source, it stays confidential and is deleted after the engagement.
We use React Native / Flutter - do you test those?
Yes. Cross-platform frameworks introduce their own attack surface (JavaScript bridge, platform channels, Dart VM). We test them specifically. We also still test the compiled native output - React Native apps produce native APK/IPA binaries, and our static/dynamic analysis works on those too.
What if our app uses certificate pinning - can you still test?
Yes. Bypassing certificate pinning is a standard part of our dynamic testing. We use Frida scripts and Objection to disable pinning at runtime on both iOS and Android. We then test whether your pinning implementation can be bypassed - and recommend hardening if it can.
We don't have a staging API - can you test against production?
We prefer staging but can test production safely. We use rate-limited requests, non-destructive payloads, and agreed test accounts. We never run denial-of-service tests on production without explicit written approval. There is a named contact on both sides for the duration, and testing stops on request without argument.
How long does a mobile security assessment take?
Single platform: 5-7 working days. Dual platform: 7-10 working days. Rush delivery (3-4 days) is available for an additional fee. The timeline depends on app complexity, number of API endpoints, and whether we're testing MASVS L1 or L1+L2.
What's the difference between MASVS L1 and L2?
L1 covers standard security - what every app should have: secure communication, authentication, data storage, and code quality. L2 adds defense-in-depth for apps handling highly sensitive data (finance, health, government): anti-reversing, tampering detection, biometric auth bypass testing, and advanced code hardening. L1 is the usual starting point; L2 tends to become necessary ahead of a first enterprise deal.
Scope your mobile app testing engagement.
Thirty minutes on a call and you have a fixed price, a testing date and a walkthrough of the platform against your own scope.