Key points
- Covers the compiled binary, on-device data, runtime behaviour and the backing API — not just a static scan of the package.
- Mapped to OWASP MASVS L1/L2 so results line up with what auditors and enterprise customers ask for.
- Findings arrive as they are confirmed, so your team starts fixing in week one instead of waiting for a report.
- Every fix is retested free within 30 days of the report.
An app store review checks that your app does not crash. It does not check whether the JWT is sitting in plain text in SharedPreferences, whether certificate pinning can be turned off with eight lines of Frida, or whether an exported activity lets any installed app open the account screen with someone else's user ID. That is what this assessment is for.
What the engagement covers
Static analysis of the binary
APK/IPA unpacked and decompiled: hardcoded API keys and secrets, debuggable and backup flags, exported components, weak crypto primitives, third-party SDKs pulling in known-vulnerable dependencies, and whatever the build pipeline accidentally shipped in the assets folder.
Local data storage review
SharedPreferences, Keychain, SQLite and Realm databases, cached network responses, logs, screenshots in the app switcher, and clipboard leakage — inspected on both rooted/jailbroken and stock devices.
Transport security
TLS configuration, certificate and public-key pinning, pinning bypass resistance under Frida and objection, cleartext traffic exceptions, and whether the app fails open when interception is detected.
Runtime and platform attacks
Root and jailbreak detection strength, debugger and hooking resistance, deeplink and custom URL scheme abuse, IPC and intent handling, WebView configuration, and biometric authentication that can be walked around entirely.
API and backend testing
The endpoints the app talks to are tested as first-class targets: authorisation on every object reference, token lifetime and revocation, rate limiting, mass assignment, and business-logic abuse such as replaying a price or skipping a payment step.
Build and release hygiene
Signing configuration, obfuscation coverage, third-party analytics leaking PII, crash reporters shipping tokens, and staging endpoints left reachable in the production build.
How it runs
-
01
Scope and authorisation
Builds, test accounts, environments, test window and a signed authorisation letter. Production data is never exfiltrated.
-
02
Reconnaissance
App architecture walkthrough, attack surface mapping, and a threat model that decides where the testing hours go.
-
03
Static and dynamic testing
Decompilation and code review alongside instrumented runtime testing on physical devices and emulators, across the OS versions you actually support.
-
04
Exploitation and chaining
Issues are chained to prove real impact — an information leak plus a missing authorisation check is an account takeover, not two low-severity notes.
-
05
Report and remediation call
Executive summary, technical detail with reproduction steps, and a working session with your developers to walk through the fixes.
-
06
Free retest
Once fixes ship, every finding is retested and the report is reissued with the closed status — the version you hand to customers.
What you receive
- Executive summary written for people who do not read stack traces
- Technical findings with CVSS 4.0 severity, evidence and reproduction steps
- Code-level remediation guidance for your platform and framework
- OWASP MASVS coverage matrix showing what was tested and what passed
- Remediation walkthrough call with the engineering team
- Retest report and an attestation letter for customers and auditors
Who this is for
- Fintech and payments apps
- Healthcare and telemedicine apps
- Apps facing an enterprise security questionnaire
- Teams shipping their first funded release
Questions about this engagement
Do you need the source code?
No. Grey-box testing with a signed build and test accounts is the default and mirrors what a real attacker can reach. Source access makes the review deeper and cheaper per finding, so share it if you can.
Will testing touch production data?
Testing runs against a staging environment wherever one exists. If production is the only option, the rules of engagement fix the accounts, data and actions in scope in writing before anything starts.
Do you test Flutter and React Native apps?
Yes. Cross-platform builds get extra attention because the Dart or JavaScript bundle often ships more logic — and more secrets — inside the package than a native app would.
How is this different from an automated scan?
A scanner flags patterns. This assessment proves exploitability, chains issues into real impact, and rules out the false positives that make scanner output unusable for a developer.