We assess your iOS and Android apps the way a motivated attacker would: decompiled, instrumented, and running on hardware they control, with the APIs behind the app tested just as thoroughly. Every engagement is aligned to OWASP MASVS and MASTG and executed by senior practitioners.
A mobile application spans the binary on the device, the platform it runs on, and the services it talks to. We test all three layers, on both platforms, from a position of full device control.
We take the app apart at rest: iOS keychain entries and their protection classes, Android Keystore usage, SQLite and Realm databases, property lists, shared preferences, WebView caches, application logs, and whatever survives into device backups. Sensitive data has a habit of landing where developers never intended, and we check every location the platform offers.
Every connection the app opens is intercepted and examined. We verify TLS configuration, hunt for cleartext traffic and overly broad ATS or network security config exceptions, and test whether certificate pinning exists, whether it covers every channel including SDK traffic, and how quickly it falls to runtime bypass from a privileged position on the device.
Deep links, custom URL schemes, universal links, exported activities, services, broadcast receivers, and content providers all extend your attack surface to other software on the device. We probe each interface for injection, hijacking, and data leakage, alongside pasteboard exposure, app extensions, WebView bridges, and permission handling.
We decompile and disassemble release builds to learn what an attacker learns from the package: obfuscation coverage, leftover debug symbols and verbose logging, insecure cryptographic API usage, and the strength of anti-tampering controls. If your app carries intellectual property or security logic on the client, this is where it stands or falls.
Using Frida and comparable instrumentation tooling on jailbroken and rooted devices, we hook methods, tamper with application logic at runtime, and attempt to bypass jailbreak detection, root detection, and pinning. The result is a realistic measure of how your resiliency controls behave against an attacker who owns the handset outright.
API keys, OAuth client secrets, encryption keys, and service credentials shipped inside the package are recoverable by anyone who downloads the app. We search compiled code, string tables, property lists, resources, and configuration files for embedded secrets, then demonstrate exactly what each recovered value grants access to.
A mobile app is a client for services you run elsewhere, and most exploitable impact lives on the server side of that connection. We test the APIs the app depends on for broken object-level authorization, authentication weaknesses, session handling flaws, and endpoints that trust the client more than they should. A mobile assessment that stops at the binary answers half the question.
Dynamic testing runs on jailbroken iOS and rooted Android hardware alongside stock devices. That vantage point reflects your actual adversary, who chooses their own equipment, and lets us evaluate your detection controls honestly instead of assuming they hold. Where MASVS resiliency requirements apply, we measure the effort each control adds rather than recording a simple pass or fail.
Four stages, each with a defined output. You know before testing begins what we will do, on which builds, and against which backend environment.
We agree on platforms, builds, and a target MASVS level, then arrange access: test accounts across user roles, a backend environment we are authorized to attack, and distribution via TestFlight, IPA, or APK. For white box work we also take source code and build configurations. Rules of engagement are signed before any traffic flows.
Testers decompile and analyze the binaries, then work through MASTG test cases on jailbroken and rooted devices: storage inspection, traffic interception, runtime instrumentation, IPC probing, and controlled attacks on the backend APIs. Every suspected issue is verified by hand before it is written down.
Within five business days of the final day of testing you have the report: an executive summary, verified findings with reproduction steps and evidence, CVSS v3.1 severity ratings, and remediation guidance for each issue. A live debrief call follows, where the testers walk your engineers and leadership through what they found.
When your fixed builds are ready, we put them back on the same devices for the included retest of every reported finding, then reissue the report with confirmed results. The engagement ends with a document you can hand to customers and auditors, not an open list of known issues.
Mobile testing here follows the OWASP Mobile Application Security Verification Standard and its companion testing guide. You choose the assurance level, we test to it, and the report states plainly which requirements were exercised.
MASVS defines what a secure mobile application looks like; MASTG defines how to verify it. We scope every engagement to a target verification level: MASVS-L1 as the baseline any app should meet, MASVS-L2 for apps handling sensitive data such as payment, health, or credential material, and the MASVS-R resiliency controls where reverse engineering and tampering sit inside your threat model.
Findings map to the specific requirements they violate. That gives your team a defensible statement of coverage to show customers and auditors, rather than a vague assurance that the app was tested at some point.
The output of a mobile assessment has to serve the leadership deciding which risks to accept and the engineers rebuilding what we broke. Both read the same document, written by the people who did the testing.
Delivery happens over an encrypted channel chosen during scoping rather than plain email, and the report and evidence remain yours to retrieve after the engagement closes.
Either works, and the best answer is usually both. A release-representative build is essential when resiliency controls are in scope, because obfuscation, pinning, and detection logic often exist only in release configurations. A debug build speeds up instrumentation and lets us spend more of the budget on depth. We typically test the release build for resilience and transport behavior while using a debug build to accelerate everything else, and we agree on the exact builds at scoping.
Yes, and most engagements cover both. The platforms differ enough in storage mechanisms, IPC models, and hardening behavior that findings rarely transfer cleanly from one to the other, so each platform gets its own test pass and its own findings. Apps built with cross-platform frameworks such as React Native or Flutter still ship platform-specific packages, and we test those the same way, with additional attention to the framework layer itself.
Yes, by default. Mobile testing without the API behind it is incomplete, because the binary is only a client and most exploitable impact sits server side. We intercept the app's traffic and test the endpoints it uses for authorization flaws, session handling weaknesses, and excessive trust in client-supplied data. If your API surface is large or shared with web clients, a dedicated API security assessment can extend that coverage beyond what the mobile app exercises.
We treat detection as a control to be measured, not an obstacle to be worked around quietly. Testers attempt to bypass jailbreak and root detection using runtime instrumentation and patching, and the report records how much effort each bypass required. That number matters: detection logic is defense in depth that raises attacker cost, not a boundary that keeps them out, and pretending otherwise produces a misleading report. If your threat model calls for MASVS-R, we assess against those requirements specifically.
Yes, as they behave inside your app. We examine what data each SDK collects and transmits, which permissions and entitlements it inherits, whether its network traffic honors your pinning and TLS posture, and whether it writes sensitive material to storage your own code keeps clean. We do not attack an SDK vendor's infrastructure without authorization, but you receive a clear account of the exposure each dependency introduces and the configuration changes that reduce it.
Tell us your platforms and what the app handles. Within a few business days you will have a proposed MASVS target level, engagement model, and start date.