Android App Penetration Testing Checklist for 2026

The OWASP Mobile Application Security project publishes three linked documents. MASVS is the security standard: what a secure mobile app should do. MASWE is a list of mobile weaknesses, and MASTG is the testing guide with the techniques and tests. A good Android assessment maps its findings to these so you can show a customer or auditor what was covered. Ask your testers which control set they use.

Since 31 August 2026, new apps and app updates on Google Play must target Android 16 (API level 36) or higher, and the extension window Google offered ended on 1 November 2026. Apps that target an older level can stop being shown to users on newer Android versions. Raising your target level brings the platform's newer protections, and it also changes behavior: permissions, background work, file access and exported components all work differently. Re-testing after a target-level change is sensible, because a fix for compatibility can open a gap.

The app package

• Manifest and components. Exported activities, services, receivers and content providers that other apps can call, debuggable builds, and the backup flag that lets data be copied off the device.
• Hardcoded secrets. API keys, tokens and passwords inside the app, which anyone can read by unpacking it.
• Code protection. How easily the app can be decompiled and modified, and whether it detects tampering or a rooted device.

Data on the device

• What is stored in shared preferences, databases and files, and whether it is encrypted with keys kept in the Android Keystore.
• What reaches logs, screenshots, the clipboard and the recent-apps view.

Network traffic

• Cleartext traffic, weak TLS settings and the network security configuration.
• Certificate pinning, and whether it can be bypassed with a hooking tool.

Platform interaction

• Deep links and app links that open sensitive screens, and intents that carry data.
• WebViews that run JavaScript, load remote content or expose native functions.
• Authentication and biometric prompts, and what happens after a session expires.

The API behind the app

Most serious mobile findings are on the server. A tester takes the requests the app makes and tests them directly for broken authorization, missing rate limits and data exposure. See our API testing checklist.

Static analysis with MobSF, jadx and apktool shows what is inside the package. Frida and objection hook the running app to inspect and change behavior at runtime. Burp Suite or mitmproxy intercepts traffic, and adb gives access to a test device. Automated scanners are a starting point only, because they cannot tell whether a finding matters for how your app is used.

• A release build and, if useful, a debug build of the same version.
• Test accounts for every user role, with sample data that is not real.
• A rooted test device, or permission to use emulators.
• The API documentation and the environment the app talks to.
• A list of what is out of scope, such as a third-party SDK or payment page.

1. Remove debug flags and test endpoints.
2. Move secrets out of the package and into server-side calls.
3. Disable cleartext traffic and review the network security configuration.
4. Restrict exported components to what is needed.
5. Test on the Android versions your users have, including the target level.

Our engineers test the app and its API together, then write a report mapped to the OWASP standards. See mobile application penetration testing and the cost guide for mobile apps, or request a scoping call.

Facts in this article were checked on 4 November 2026 against these primary sources:

• Google Play: target API level requirements
• OWASP Mobile Application Security (MASVS, MASWE, MASTG)