Mobile application security testing: Tools & methods guide

Security coverage is only part of a mature QA process — pairing it with mobile app performance testing ensures releases are both safe and fast before they ship. Teams building mobile apps from scratch get the most value by baking this into the mobile app development process itself, rather than testing for it after the fact.

Mobile app security testing: The short answer

Static analysis catches insecure code patterns before a build ever runs, but it misses the runtime behavior that only dynamic analysis exposes, such as broken certificate pinning or logic flaws reachable through Frida hooks.

Effective mobile application security testing runs both static and dynamic analysis, mapped against OWASP mobile application verification standard (MASVS) and mobile application security testing guide (MASTG) controls across app components and stored data.

MobSF, Drozer, and Frida cover different parts of an OWASP MASTG-mapped checklist, and picking the wrong one for the job is how teams end up with either a false sense of coverage or a pile of false positives nobody triages. 71% of organizations admit compromising mobile app security due to time-to-market pressure (Guardsquare (cited in IT Pro article), 2024).

This guide covers tool selection, a MASTG-mapped checklist, and where each method's false positives pile up when testing mobile applications ahead of release.

Why mobile Apps need different testing than web Apps

Mobile security testing has to account for an attack surface that a web app simply doesn't have: the device itself. A web app's server sits behind infrastructure the vendor controls; a mobile app ships its binary onto a phone the attacker owns outright, making root detection, jailbreak detection, and binary reverse engineering core parts of any mobile application security testing scope, not optional extras.

Getting this right depends on following core mobile security practices from the earliest stages of development, not bolting them on before release. Root and jailbreak detection are two of those core practices.

On Android, that means checking whether the app detects Magisk or rooted emulators before trusting local storage or biometric prompts. On iOS, jailbreak detection has to survive tooling like Frida and objection, both built for exactly this kind of bypass testing.

Binary reverse engineering is the other half. Anyone with the APK or IPA can decompile it, so hardcoded keys, weak certificate pinning, and exposed intent filters are all fair game offline, with no server request required. OWASP's MASWE weakness catalog documents this class of platform-specific issue separately from server-side OWASP Top 10 risks, because the remediation path, obfuscation, attestation, runtime checks, is device-layer, not backend-layer.

SAST vs DAST vs IAST: Which method covers what

Static analysis, dynamic analysis, and IAST answer three different questions, and none of them alone satisfies an OWASP MASVS review. Static analysis inspects the APK or IPA without execution.

MobSF's static scanner flags hardcoded secrets, insecure certificate pinning implementations, and manifest misconfigurations in minutes, but it can't confirm runtime behavior like TLS bypass under an active man-in-the-middle proxy.

Dynamic analysis fills that gap. Tools like Drozer exercise exported components, content providers, and intents on a running instance, while Frida hooks into process memory to defeat root detection and certificate pinning at runtime — the exact bypass techniques OWASP MASTG test cases assume an assessor will attempt.

IAST sits between the two, instrumenting the app during automated test execution to correlate a static finding with the actual data flow that triggers it. Static analysis alone tends to produce a false-positive rate high enough that triage consumes more engineer time than remediation; dynamic confirmation with Frida cuts that noise by validating which flagged issues are actually reachable at runtime.

MASTG-mapped checklists work best when static findings get a dynamic pass before they reach a severity ticket.

OWASP MASVS vs MASTG: How they fit your testing program

OWASP MASVS defines what "secure" means for a mobile app; OWASP MASTG tells you how to verify it.

MASVS is the standard: a set of security requirements grouped into resilience, cryptography, network communication, and platform interaction. MASTG is the testing guide that maps each requirement to a concrete procedure, often naming MobSF, Frida, or Drozer as the tool to run.

OWASP MASWE sits between them as the weakness enumeration. Where MASVS states a requirement ("the app must not accept a bypassed certificate") and MASTG gives you the test case, MASWE catalogs the specific weakness patterns that cause that requirement to fail. Think of it as CWE scoped to mobile.

In practice, we build our test plans backward from MASVS. According to the OWASP MASVS v2.1 documentation, the standard defines eight security domains that every review should score against, and MASTG's individually-numbered test cases (e.g. MASTG-TEST-0001 for Android local data storage) give each domain a pass/fail procedure rather than a subjective judgment call.

A MASTG-mapped checklist run against a production binary, not an emulator build, is the only version worth signing off on. Emulator runs routinely miss root-detection bypasses and hardware-backed keystore behavior that only show up on physical devices, and certificate-pinning bypasses are the most common casualty.

Netguru has applied this MASVS-backward approach on fintech engagements like CashCape, where certificate pinning and secure local storage sit squarely inside the compliance bar a lending product has to clear before launch.

Static analysis with MobSF: What it catches and misses

MobSF automates the static analysis portion of an OWASP MASTG-mapped checklist, and it does that job well. Point it at an APK or IPA and it decompiles the binary, flags hardcoded secrets, weak crypto usage, and manifest misconfigurations, then scores the build against OWASP MASVS controls in minutes rather than the hours a manual review takes.

MobSF's static scanner routinely catches issues like API keys sitting in SharedPreferences in plaintext or an exported activity shipped with no permission check — exactly the class of finding MASVS-STORAGE and MASVS-PLATFORM test for. That kind of pass matters most on compliance-heavy builds: KYC and payments infrastructure like Dock Financial's is exactly where regulators expect a documented static-analysis trail, not just a fixed bug.

What it misses matters more for release decisions. MobSF cannot exercise runtime behavior: it will not tell you whether certificate pinning actually blocks a proxy at connection time, whether root detection triggers under Frida instrumentation, or whether business logic flaws surface once a session token is live.

Static analysis also produces a meaningful false-positive rate: expect to triage flagged crypto calls that are dead code, and third-party SDK warnings that carry no exploitable path in your app.

Treat MobSF as the first gate in a pipeline, not the whole security testing program. It clears the cheap, high-volume findings so a security engineer's time on dynamic analysis with Drozer or Frida goes toward the vulnerabilities that only show up when the mobile application is actually running.

Dynamic analysis with frida and drozer

Frida and Drozer cover the dynamic half of an OWASP MASTG-mapped checklist, but they attack different layers of a running app and rarely replace each other.

Frida hooks into process memory at runtime, letting an engineer intercept function calls, dump decrypted payloads, and bypass root detection or certificate pinning without touching source code. Drozer instead targets Android's inter-process communication surface: exported activities, content providers, broadcast receivers, and the permission boundaries between them. They rarely overlap in practice.

A bypassable certificate-pinning implementation can look entirely correct at rest — a static-analysis pass with MobSF won't catch it. The gap only shows up once Frida attaches to the running app on a physical device and the TLS handshake actually executes. That's the core limitation of static analysis: it reads code, not behavior.

Drozer covers a different gap: an exported content provider that leaks user session data to any other app on the device is a class of finding that lives squarely in OWASP MASWE's IPC weakness category, and neither MobSF nor Frida catch it without deliberate IPC fuzzing.

Run both against a production-signed binary, not an emulator build. Root and jailbreak detection routines, plus several anti-tampering checks, behave differently once instrumentation is present, and emulator testing understates how many of these controls actually hold under real device conditions.

Common mobile vulnerabilities testing should catch

Insecure data storage, certificate-pinning bypasses, and exposed IPC components are the findings covered above — MASVS-STORAGE, MASVS-NETWORK, and MASVS-PLATFORM territory. The class this guide hasn't touched yet: authentication and session management, MASVS-AUTH.

Weak session handling shows up as tokens that never expire, session IDs predictable enough to guess, or biometric prompts that fall back to a PIN with no rate limiting.

None of these are exotic — they're the same weaknesses server-side apps have dealt with for years, just relocated to a device an attacker can hold in their hand and attack offline, with no rate-limiting server in the loop to slow them down.

Drozer earns its place twice here: once for the exported activities, content providers, and broadcast receivers Android's component model leaves open by default, and again for any authentication logic reachable through those same exported components without going through the app's normal login flow.

Integrating mobile security testing into CI/CD

Most teams bolt static analysis onto a pipeline and call it done, then get flooded with low-severity noise that developers learn to ignore. Gating on severity thresholds, not raw finding counts, is what makes mobile security testing survive contact with a release schedule.

A workable pattern: run MobSF static analysis on every pull request, block merges only on MASVS-mapped critical and high findings (hardcoded secrets, missing certificate pinning, exported components without permission checks), and post medium/low findings as comments instead of failing the build. A minimal GitHub Actions step for the blocking scan looks like this:

- name: MobSF static scan
  run: |
    HASH=$(curl -s -F "file=@app-release.apk" \
      -H "X-Mobsf-Api-Key: $MOBSF_API_KEY" \
      $MOBSF_URL/api/v1/upload | jq -r .hash)
    curl -s -X POST $MOBSF_URL/api/v1/scan \
      -H "X-Mobsf-Api-Key: $MOBSF_API_KEY" \
      --data "scan_type=apk&hash=$HASH" > scan.json
    # fail the job only on MASVS-mapped critical/high findings
    python scripts/mobsf_gate.py scan.json --severity critical,high

Dynamic analysis runs less often, typically nightly against a staging build, because Drozer and Frida instrumentation take longer and need an emulator or rooted device farm. Test against production-signed binaries at least weekly, not just debug builds on emulators, since obfuscation and pinning behavior differ under release configuration.

Map each gate to a specific OWASP MASTG test case ID in the pipeline config. When an auditor or new engineer asks why a build failed, the answer should be a checklist reference, not a Slack thread.

Step-by-step mobile app security testing checklist

A mobile app security testing checklist mapped to OWASP MASTG gives release teams a repeatable gate instead of ad-hoc review.

Run these steps in order — don't ship past step 6 without a signed-off exception.

1. Static analysis pass. Run MobSF against the release APK/IPA, not a debug build, to catch hardcoded secrets, insecure storage, and manifest misconfigurations before dynamic testing starts.
2. Map findings to MASVS controls. Tag each finding against OWASP MASVS categories (storage, crypto, network, auth) so severity reflects actual risk, not tool noise.
3. Cross-check against MASWE weakness entries. OWASP MASWE gives finer-grained weakness patterns than MASVS controls alone, useful for triaging edge cases MobSF flags as informational.
4. Dynamic analysis on a physical device. Drozer for Android component exposure (exported activities, content providers), Frida for runtime instrumentation, bypass root/jailbreak detection and certificate pinning to test what the app does under TLS interception, not just what it declares.
5. Manual penetration testing on business logic. Automated tools miss authorization flaws and session handling bugs; a scoped penetration test closes that gap before release.
6. Re-run static analysis on the signed production binary. Emulator-only testing misses obfuscation and packaging differences that show up in the store build.

Third-party SDKs and testing production binaries vs emulators

Third-party SDK risk is the blind spot most emulator-based testing misses entirely, and it's also where OWASP MASVS's code-quality expectations get tested hardest: MASVS-CODE expects third-party components to be inventoried and kept current, not just your own code to be clean.

Ad networks and analytics kits routinely request excess permissions or phone home with device identifiers, a pattern Verizon's Mobile Security Index has flagged as a recurring vector across app ecosystems for several years running. MobSF's dependency scan regularly surfaces outdated crypto libraries or exposed API keys buried three SDKs deep, and research shows 85% of mobile apps contain security vulnerabilities, many from third-party components (NowSecure Mobile App Risk Intelligence).

Emulators also lie about behavior in ways that matter for security testing. Root detection, TLS pinning bypass attempts, and anti-tampering checks often behave differently on a rooted Pixel than in an Android Studio emulator, because SDKs increasingly fingerprint the runtime itself.

Running Drozer and Frida against physical devices routinely surfaces privilege-escalation paths that emulator passes mark clean — another reason MASTG treats device-based dynamic testing as mandatory, not optional, before signing off a release.

Binary reverse engineering is the real threat model you're defending against at release, not static code review. Test the signed, obfuscated release binary, the artifact an attacker actually gets, using Frida for runtime instrumentation and Drozer for inter-process communication attacks, on real hardware whenever the build ships with anti-emulation logic.

open source vs commercial mobile security testing tools

MobSF covers static and dynamic analysis for both Android and iOS out of the box, while Drozer is Android-only and built specifically for exploiting inter-process communication (IPC) surfaces: content providers, exposed activities, broadcast receivers.

Commercial suites like NowSecure or Checkmarx add managed vulnerability scanning pipelines and compliance reporting, but at a licensing cost that rarely fits a 50-person engineering team's tooling budget.

MobSF's static pass reliably catches the bulk of MASVS-mapped findings a full manual audit would confirm, with false positives concentrated in hardcoded-secret detection on obfuscated builds — exactly the noise a dynamic pass with Frida is good at filtering out before it reaches a severity ticket.

Our view: open source covers most MASTG test cases for free. Commercial tools earn their cost only when you need audit trails or a dashboard for a compliance team, not more coverage.

FAQ: Mobile application security testing