16 Mobile App Security Testing Tools Current for 2026

Last updated: August 2026. Written by Josh Hutcheson, OnlineCourseing editor. Every tool below was loaded at its current URL and checked against its source repository before publication — four tools from our previous version are dead and six had been renamed or acquired out from under their old links. See our review methodology.

QUICK VERDICT

Mobile app security testing splits cleanly into two jobs that get confused with each other. One is the hands-on assessment a penetration tester runs against a single app — pulling the binary apart, watching its traffic, rewriting its behaviour at runtime. The other is automated scanning across a portfolio of apps, on a schedule, producing evidence for a compliance requirement. Almost every tool below is built for one or the other, and picking from the wrong half is the most common mistake here.

This guide covers both, separated so the distinction is obvious. It also documents what changed, which in this category is unusually violent: of the thirteen tools this article recommended in its previous version, four no longer exist and six have been renamed or acquired. One of the dead ones now points at an events-management company that bought the abandoned domain.

What mobile app security testing actually covers

Mobile app security testing is the assessment of an Android or iOS application across four surfaces: what it stores on the device, how it communicates over the network, how it uses the platform’s own security controls, and how well it resists being reverse-engineered or tampered with. It is an application security discipline, not a device one — the target is the app, not the handset.

The reference standard is the OWASP Mobile Application Security Verification Standard (MASVS), which divides that surface into eight control groups: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE and MASVS-PRIVACY. Its companion, the Mobile Application Security Testing Guide (MASTG), documents how to test each one and maintains a registry of the tools that do it. Most of the open-source tools below appear in that registry, which is a better signal of relevance than any vendor’s own claim.

WORTH KNOWING IF YOU ARE FOLLOWING AN OLDER GUIDE

Android and iOS need different toolchains

A tool that works on one platform usually does not work on the other, and the reason is structural.

Android ships a first-party debug bridge with a shell, apps are distributed as APKs that can be decompiled to readable Java, and sideloading is a supported operation. The tooling reflects that: decompilers, static analysers and a debug bridge you can just use.

iOS encrypts App Store binaries, enforces code signing at load time, sandboxes strictly and offers nothing resembling adb. So the iOS toolchain spends most of its effort on problems Android does not have — recovering a decrypted binary from memory, signing and sideloading an app, reimplementing device communication. We cover that end in depth in our iOS penetration testing guide.

Only a handful of tools genuinely span both: MobSF, Frida, objection, and the network proxies. Those are the ones to learn first.

What a mobile app security test actually finds

Knowing the tools matters less than knowing what you are looking for. Across real engagements the same six classes of finding account for most of what ends up in a report, and each maps to a MASVS control group.

1. Sensitive data left on the device (MASVS-STORAGE). The most common finding by a wide margin, and the least exciting: an authentication token in a plist or SharedPreferences file, a database left unencrypted in the app sandbox, a cached API response holding personal data, credentials written to logcat during a debug flow that shipped. Use the app normally for ten minutes, then read everything it wrote.
2. Hardcoded secrets in the binary (MASVS-CODE). API keys, backend URLs, encryption keys and test credentials compiled into the app. On Android, decompiling with jadx and searching the whole tree finds these in minutes. Developers frequently assume compilation is obfuscation. It is not.
3. Weak or misused cryptography (MASVS-CRYPTO). Hardcoded keys or initialisation vectors, ECB mode, a home-rolled cipher, or a key derived from something predictable such as a device identifier. The algorithm is usually fine; the way it is keyed usually is not.
4. Improper certificate validation (MASVS-NETWORK). Either no pinning at all, or a trust manager that accepts any certificate because someone disabled validation to get past a proxy in development and never re-enabled it. This is exactly what you discover the moment Burp intercepts traffic it should not have been able to read.
5. Exposed platform components (MASVS-PLATFORM). On Android, exported activities, content providers, services and broadcast receivers that other apps on the device can reach and should not — this is precisely the surface drozer was built to probe. On iOS the equivalents are custom URL schemes and pasteboard use.
6. No resilience to tampering (MASVS-RESILIENCE). Absent or trivially bypassed root and jailbreak detection, no debugger detection, no integrity checking. For a general business app this is often a low-severity note; for a banking, payments or DRM-bearing app it is frequently the section the client cares most about.

Two observations that shape how you spend your time. First, most of that list is discoverable without any exotic technique — it needs systematic coverage rather than cleverness, which is why working the MASVS groups in order beats improvising. Second, the automated tools are good at classes 1 through 3 and poor at 4 through 6, because the last three depend on understanding what the app is supposed to do. That division is the honest case for why a scanner does not replace a tester.

The cross-platform core

These five cover the majority of real assessment work on either platform. All are free.

1. MobSF — the automated first pass

Mobile Security Framework takes an APK or IPA, or zipped source, and returns a one-page report: compiler protections, entitlements and exported components, hardcoded secrets and strings, network security configuration, and a static analysis of the code. It does static and dynamic analysis and API testing, runs locally so nothing sensitive leaves your machine, and has 21,667 GitHub stars. OWASP catalogues it for both platforms.

MobSF will not find your best finding. It clears the obvious ground in minutes so your manual time goes somewhere useful, and gives you a consistent baseline across every app you test. Start every engagement here.

2. Frida — runtime instrumentation

Frida attaches to a running process and lets you inspect and rewrite its behaviour from JavaScript: hook any method, read or write memory, change return values, trace calls. It is the single most important tool in mobile security testing and, at 21,795 stars with releases shipping continuously, the one that everything else is built on top of.

The everyday uses are the same on both platforms — defeat a root or jailbreak check, bypass certificate pinning, pull a key out of memory at the moment it is used, log a method to understand an undocumented protocol.

3. objection — Frida with the common tasks pre-built

objection (9,352 stars) sits on Frida and turns the repetitive work into single REPL commands: disable SSL pinning, browse and pull the app’s storage, dump the iOS Keychain, read plist and preference files, and repackage an app with the Frida gadget so it runs on a non-jailbroken or non-rooted device. Most testers live in objection and drop to raw Frida only when it does not cover the case.

4. Burp Suite — the traffic proxy

Burp Suite is the standard for intercepting, inspecting and rewriting an app’s network traffic, and OWASP catalogues it as a MASTG network tool. Point the device at Burp, install and explicitly trust its CA certificate, and you see the API the app actually talks to — which is usually where the more serious findings live. Community edition is free; Professional adds the automated scanner.

Note that on both platforms, trusting the certificate is only half the battle. Apps with certificate pinning reject your proxy anyway, which is what objection’s pinning bypass is for. Apps built on Flutter bundle their own TLS stack and ignore the system trust store entirely — identify the framework before you spend an afternoon debugging a bypass that was never going to work.

5. ZAP — the free proxy alternative

ZAP is a fully-featured intercepting proxy and scanner, free and open source, at 15,709 GitHub stars. It does most of what Burp Community does plus active scanning, which Burp reserves for the paid tier.

Name check: this tool is no longer “OWASP ZAP”. The project left OWASP and is now ZAP by Checkmarx — its own repository describes itself as “The ZAP by Checkmarx Core project” while the homepage still stresses that ZAP “is an independent Open Source project.” Our previous version called it OWASP ZAP and linked the old OWASP wiki page, which now returns a 404.

Learn the methodology behind these tools →

Android-specific tools

6. drozer — the Android assessment framework

drozer lets you assume the role of an app and interact with other apps through Android’s IPC mechanisms — probing exported activities, content providers, services and broadcast receivers for components that should not be reachable. It describes itself as “the leading security assessment framework for Android,” has 4,598 stars, and is actively maintained with commits as recent as April 2026.

Ownership check: drozer has changed hands twice since most articles last linked it. It began at MWR InfoSecurity, moved to F-Secure Labs, then WithSecure, and now lives under ReversecLabs. Both older GitHub paths redirect there. Our previous version linked labs.f-secure.com, which now lands on a generic F-Secure articles page with no drozer on it.

7. jadx — the decompiler

jadx converts Dalvik bytecode back into readable Java. At 50,272 GitHub stars it is by a wide margin the most-adopted tool on this page, and it is the fastest route from “I have an APK” to “I can read what this app does.” Its GUI includes search across the whole decompiled tree, which is how most hardcoded secrets get found. OWASP catalogues it.

8. Apktool — unpack, patch, repack

Apktool (25,418 stars) decodes an APK’s resources and manifest to near-original form and rebuilds it afterwards. Where jadx is for reading, Apktool is for changing — patching smali to disable a check, editing the network security configuration to trust your proxy certificate, then repacking and re-signing. It is the standard answer when an app resists instrumentation.

9. Android Debug Bridge (adb)

adb is Google’s own command-line bridge to a device or emulator: install and remove apps, open a shell, pull files out of an app’s data directory, read logcat, forward ports. It ships with the Android SDK platform tools and it is the substrate everything else runs on. iOS has no equivalent, which is a large part of why iOS testing is harder.

10. apkeep — getting the APK in the first place

apkeep, maintained by the Electronic Frontier Foundation (2,031 stars), downloads APKs from several sources by package name. It solves the unglamorous first problem of any third-party assessment: obtaining the exact build you are supposed to be testing. If the client can hand you the APK from their CI pipeline, take that instead.

iOS-specific tools

The iOS side has its own toolchain and its own guide on this site; these two are the ones you cannot work without.

11. frida-ios-dump — decrypting the binary

frida-ios-dump (3,922 stars) recovers a decrypted IPA from a running app’s memory. Because App Store binaries are FairPlay-encrypted, nothing static happens on iOS until you have run this or been handed an unencrypted build. There is no Android equivalent because Android does not encrypt its packages.

12. Grapefruit — iOS assessment in a browser

Grapefruit (1,379 stars, formerly Passionfruit) puts a web interface over Frida for browsing an iOS app’s classes, files, Keychain items and preferences. It is the fastest way to survey an unfamiliar app before deciding where to dig.

The full iOS kit — Keychain-Dumper, class-dump, SSL Kill Switch 3, Sideloadly, palera1n and the rest — along with the workflow that uses them, is covered in our iOS penetration testing guide.

Commercial MAST platforms

These solve a different problem from everything above. You are not buying better analysis than a skilled tester with Frida produces — you are buying scale, repeatability and a report format an auditor accepts. If your requirement is “scan every release of forty apps and evidence it,” this is the right half of the page. If it is “find the flaws in this one app,” it is not.

This category consolidates constantly, and four of the vendors our previous version named now trade under different owners. Current names, verified by loading each old URL and following where it lands:

13. Corellium

Corellium runs virtualised iOS and Android devices in the cloud with root-level access on arbitrary OS versions. OWASP catalogues it as a MASTG tool. For a consultancy testing across many OS versions it removes the entire hardware-procurement problem; for an individual learner it is priced out of reach.

14. Black Duck (formerly WhiteHat Security)

Our previous version recommended “WhiteHat Sentinel Mobile Express.” That URL now redirects to Black Duck’s platform page. WhiteHat passed through NTT and Synopsys before the software-integrity business was spun out as Black Duck, and the Sentinel Mobile Express product name no longer appears. The capability lives on inside the Polaris platform.

15. HCL AppScan (formerly IBM Application Security on Cloud)

IBM sold AppScan to HCL, so “IBM Application Security on Cloud” is now HCL AppScan. Our old IBM link redirects to a generic IBM Garage page with no product on it. AppScan still imports APK and IPA files and reports findings with remediation guidance — under the new owner.

16. Veracode

Veracode remains an established application security vendor, but the specific product our previous version named — “MAST by Veracode” — is no longer part of its lineup. Veracode now organises around SAST, DAST, SCA, container scanning and penetration testing as a service, with mobile handled inside those, not as a separately branded MAST product.

Two others from the old list survive under new ownership without a product rename: Kiuwan is still trading as a code-security platform, and Fortify is intact but is now OpenText Fortify — Micro Focus was acquired by OpenText, and the old microfocus.com application-security URL redirects into OpenText’s catalogue.

The 16 tools at a glance

Star counts are from the GitHub API on 30 August 2026. Every open-source entry was confirmed to have a recent commit, not merely a recent pushed_at date — see the note under the removals table.

WHY THERE ARE NO AFFILIATE LINKS ON THIS PAGE

What we removed and what got renamed

The previous version of this article recommended thirteen tools. Four are dead and six had been renamed or acquired while our links still pointed at the old owners. Documenting it rather than quietly deleting, because most competing lists in this category still carry the same entries.

Dead — removed entirely

Renamed or acquired — kept, relinked, and corrected

Two lessons generalise from that pair of tables, and both are worth carrying to any tool list you read. First, a retired product almost never returns an error. Five of the six renames above answer HTTP 200 because the vendor redirected the old URL somewhere useful to them — you have to compare the URL you requested against the URL you actually landed on. Second, a repository’s “last pushed” date is not its last commit. QARK reports activity in 2024 while its newest commit is from 2019; the gap comes from ref writes that are not code changes. Check the commit history per branch, not the summary field.

How to choose

The decision is mostly about which of the two jobs you are doing.

1. Assessing one app properly. MobSF for the automated pass, then Frida and objection for everything manual, with Burp or ZAP on the traffic. Add jadx and Apktool on Android, frida-ios-dump and Grapefruit on iOS. Total cost: nothing.
2. Scanning a portfolio on a schedule. A commercial MAST platform. You are paying for coverage, integration into CI, and reporting an auditor will accept — not for better findings.
3. Satisfying a specific compliance requirement. Read the requirement first. It often names the evidence format rather than the tool, and the open-source stack plus a written report can satisfy it at a fraction of the cost.
4. Testing across many OS versions. Corellium, or a shelf of older physical devices. There is no free virtualisation option for iOS.

Authorisation comes first

Every tool here is lawful to own and run against an app you own or have written permission to test. Without that permission the same actions fall under the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act 1990 in the United Kingdom, or the local equivalent. The technique is identical either way; the authorisation is the only thing that distinguishes an assessment from an offence.

Three things worth settling in writing before you install anything, because mobile testing crosses boundaries that web testing does not:

• The backend is a separate scope. An app’s traffic terminates on servers that may belong to a payments processor, an analytics vendor or a mapping API. Permission from the app owner does not extend to those endpoints.
• Store terms are not the same as the law, but they still bind you. Rooting or jailbreaking a device voids its warranty and may breach a corporate device policy even where it is perfectly legal. Test on hardware you own or on a virtual device.
• Production data. A production build talks to production infrastructure and real user records. Ask for a test environment and test accounts.

If you want to practise without any of that overhead, deliberately vulnerable targets exist for exactly this purpose: DVIA-v2 on iOS, and the OWASP MAS Crackmes, which are the reverse-engineering challenges used as worked examples throughout the MASTG itself.

Learning to use these properly

The tools are the easy part. What separates someone who can run MobSF from someone who can deliver a defensible report is the methodology underneath: scoping an engagement, working MASVS coverage systematically, capturing evidence, rating severity, and writing findings a development team can act on.

A realistic order if you are starting out: general penetration testing fundamentals first, because mobile work assumes you already understand HTTP, authentication flows and how to write up a finding. Mobile is a specialisation layered on top, not an entry point.

We rank and review the options: the best penetration testing courses covers the hands-on end and the certifications employers recognise, while ethical hacking courses and cyber security courses are better starting points if you are earlier in the journey.

Compare pentesting courses and certifications →

Browse cyber security courses →

Frequently asked questions

What tools do security testers use for mobile apps?

The free core is MobSF for automated static and dynamic analysis, Frida for runtime instrumentation, objection as the workflow layer on top of Frida, and Burp Suite or ZAP for network traffic. Android work adds drozer, jadx, Apktool and adb; iOS work adds frida-ios-dump and Grapefruit. Commercial MAST platforms such as Black Duck, HCL AppScan and Veracode solve a different problem: scanning many apps on a schedule with audit-ready reporting.

What is the best free mobile app security testing tool?

MobSF, if you need one answer. It handles both Android and iOS, does static and dynamic analysis plus API testing, runs locally so nothing sensitive leaves your machine, and produces a consistent baseline report in minutes. Pair it with Frida for the manual work, because MobSF finds the obvious problems and Frida is how you find the rest.

Is QARK still maintained?

No. LinkedIn’s Quick Android Review Kit shows a GitHub ‘last pushed’ date of 2024, which makes it look active, but its newest actual commit is from 5 April 2019. That gap is a common trap: pushed_at updates on any ref write, not only on code changes. For Android static analysis, MobSF and jadx have replaced it.

Is ZAP still called OWASP ZAP?

No. The Zed Attack Proxy left OWASP and is now ZAP by Checkmarx — its own repository describes itself as ‘The ZAP by Checkmarx Core project’, while its homepage stresses that ZAP remains an independent open source project. The old OWASP wiki page for it returns a 404. The tool itself is unchanged, free, and actively developed.

What standard should a mobile app security test follow?

The OWASP Mobile Application Security Verification Standard (MASVS), which divides the mobile attack surface into eight control groups covering storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. The Mobile Application Security Testing Guide (MASTG) documents how to test each control. Note that MASTG v2.0.0, released 30 June 2026, removed the MAS Checklist spreadsheet that earlier versions shipped.

Do I need a rooted or jailbroken device?

It helps considerably but is not always required. On Android, many tests run on a standard device or emulator, and rooting mainly buys you filesystem access and system-wide instrumentation. On iOS the constraint is tighter: without a jailbreak you must repackage the app with the Frida gadget using objection, which works on current iOS versions but limits you to that one app. Corellium is the paid alternative on both platforms.

Are commercial MAST platforms worth it over free tools?

It depends entirely on the job. For assessing a single app in depth, a skilled tester with MobSF, Frida and Burp will out-perform an automated platform. Commercial platforms earn their cost when you need to scan many apps repeatedly, integrate scanning into CI, and produce reports an auditor or client will accept without argument. You are buying scale and evidence, not better findings.

Is mobile app security testing legal?

Only against apps you own or have written authorisation to test. Without it the same actions fall under the Computer Fraud and Abuse Act in the US, the Computer Misuse Act 1990 in the UK, or the local equivalent. Note also that permission from an app’s owner does not automatically cover third-party backend endpoints the app talks to — agree the network scope explicitly, not just the app.

Related reading: iOS penetration testing · web application pentesting tools · penetration testing tools · ethical hacking tools · penetration testing methodology · best penetration testing courses · network penetration testing

Related guides

Running your testing environment on Windows? See pentest tools for Windows for the native-versus-WSL2 breakdown. For the iOS-specific workflow, see iOS penetration testing.