Android application penetration testing: from the APK to the API

Anyone can download your APK, decompile it and launch its components from another app. We test your Android application using the OWASP MASVS and MASTG methodology, on a real device and against its API, and deliver every finding with its proof of concept and the fix for your Kotlin or Java team.

Scope your project · Request an Android assessment

Rather talk it through? Call us at +34 960 730 013

OWASP MASVS — All eight categories of the standard, from storage to privacy
Components — Exported activities, services, receivers and providers, one by one
App + API — The backend the app uses is in the same scope
Retest — Verification of the fixes included

Why an Android app needs its own assessment

Android is the most widely used mobile operating system in the world and also the most open: an APK can be downloaded and decompiled in minutes, other apps on the same phone can talk to yours, and every manufacturer adds its own layer. That doesn't make Android insecure, but it does put decisions in the developer's hands that other platforms make for them.

The flaws we see most often come from there: an unprotected exported Activity any app can launch, a deep link that opens any URL in a WebView with access to app functions, a ContentProvider that exposes data, a token stored unencrypted in SharedPreferences or a network configuration that trusts user-installed certificates. Google Play review looks for malware and policy violations; it tests none of this.

An Android penetration test looks for it with an attacker's tools —decompilation, Frida instrumentation, traffic interception and direct calls to components— and organises it according to OWASP MASVS.

Anatomy of an Android app under test

Each layer is an OWASP MASVS category. Pick one to see what we test, what we usually find and the kind of evidence that comes with the finding in the report.

MASVS-STORAGE · Local storage: SharedPreferences, SQLite and Room, external storage, caches, logcat and what a backup takes with it. Typical finding: Session token stored unencrypted in SharedPreferences, with backups allowed.
MASVS-CRYPTO · Cryptography and Keystore: Algorithms and modes, keys written into the code, and use of the Android Keystore and secure hardware (StrongBox) to hold them. Typical finding: An encryption key written into the code instead of generated and stored in the Android Keystore.
MASVS-AUTH · Authentication and biometrics: Login, sessions and tokens, second factor and BiometricPrompt: whether the fingerprint unlocks a cryptographic key or just fires a callback. Typical finding: BiometricPrompt with no CryptoObject: a hook on the success callback bypasses the fingerprint.
MASVS-NETWORK · Communications: Network Security Configuration, cleartext traffic, certificate validation, certificate pinning and sensitive data in URLs. Typical finding: A network configuration that trusts user-installed certificates and allows cleartext traffic to the API.
MASVS-PLATFORM · Components, intents and WebViews: Exported activities, services, receivers and providers, deep links and App Links, PendingIntents and WebViews with JavaScript interfaces. Typical finding: An exported Activity that opens any URL in a WebView with addJavascriptInterface: a foreign website calls app functions.
MASVS-CODE · Code and dependencies: Third-party libraries and SDKs with their versions, minSdk, debug builds, input validation and what gets written to logcat. Typical finding: A production build with android:debuggable enabled and SDKs with public vulnerabilities.
MASVS-RESILIENCE · Resilience: Root detection, integrity checks with Play Integrity, anti-debugging, anti-tampering and R8 obfuscation: they raise the cost of an attack in banking or gaming apps. Typical finding: Root detection and an integrity verdict bypassed on the client because the server doesn't validate them.
MASVS-PRIVACY · Privacy and permissions: Permissions requested versus used, the Google Play data safety section and what third-party SDKs send, and when. Typical finding: Location and contacts permissions requested at launch, unrelated to the feature that needs them.

Illustrative findings and output, built from patterns that are common in Android assessments; they do not describe a specific app.

What an Android penetration test covers

Static analysis of the APK or AAB: decompilation with jadx and apktool, manifest, permissions, embedded secrets and native libraries
Exported components: activities, services, broadcast receivers and content providers, tested one by one with crafted intents
Deep links, App Links, PendingIntents and WebViews: JavaScript interfaces, file access and loading of external content
Storage: SharedPreferences, SQLite and Room, external storage, caches, logcat and backups
Cryptography and the Android Keystore
Communications: Network Security Configuration, cleartext traffic and certificate pinning
Authentication, sessions and biometrics with BiometricPrompt
Dynamic analysis with Frida on a rooted device: hooking and bypassing root, integrity and debugging controls
Privacy: permissions, third-party SDKs and consistency with the Google Play data safety section
The app's backend API: authorization between users, tokens and hidden endpoints

Methodology

Scope and testing profile: We agree which builds, features and roles are in scope and which OWASP MAS testing profile applies given the app's risk.
Manifest and static analysis: We decompile the app and review the manifest, exported components, network configuration, permissions and code for secrets and insecure patterns.
Components and intents: We launch every exported component and every deep link from outside the app, as another app installed on the same phone would.
Dynamic analysis: We instrument the app with Frida on a rooted device to see what it stores, what it encrypts and how it reacts when its controls are disabled.
Network and API: We intercept traffic, bypassing pinning if present, and test the API with two accounts per role, where the highest-impact findings appear.
Report and retest: We deliver every finding classified by MASVS category, with a proof of concept and a fix in Kotlin or Java, and verify the fixes in the new build.

Deliverables

Executive report with the business risk and remediation priorities
Technical report with a proof of concept and steps to reproduce each vulnerability
Findings classified by OWASP MASVS category, with references to MASTG test cases
Specific remediation recommendations for the Android team (Kotlin or Java) and for the backend
Wrap-up meeting with the development team
Retest of the fixes in the new build

Use cases

Banking, payments and fintech apps with financial data and biometrics
Health apps with patient clinical data
Corporate apps with access to email or internal systems, managed through MDM
Marketplaces and e-commerce with built-in payments
Messaging apps or apps holding users' private data
Startups that must pass an enterprise customer or investor due diligence

Google Play review, scanner or pentest: what each one checks

All three look at your app, but they look for different things.

	Google Play review	Automated scanner	Manual Android pentest
Goal	Malware and policy violations	Known patterns in the APK	Find what an attacker would exploit
Exported components	No	Lists them	Launches them and shows the impact
WebViews and deep links	No	Hints	Exploitation with a proof of concept
Backend API	No	No	Yes, with two accounts per role
Deliverable	Approval or rejection	Unvalidated list	Report with PoC, fix and retest

Compare with

Android penetration testing FAQ

Do you need the source code of the Android app?

It's not essential: we can work with the APK or AAB, the way an attacker would. Source code lets us go further in the same time, especially on business logic, and point recommendations to the exact line.

Can you run the test without a physical device?

Part of the static and network analysis can be done on an emulator. For full dynamic analysis with Frida, and for anything hardware-dependent such as the Keystore or biometrics, we use rooted physical devices that we provide.

Do you test the obfuscated production app?

Yes. Obfuscation with R8 or commercial tools makes analysis harder but doesn't prevent it, and measuring how costly it is to get past is precisely part of resilience testing. If you want more depth in the same time, an unobfuscated build helps.

Does it include the API the app uses?

Yes. Most of an app's serious findings are in its backend: endpoints that return other users' data or accept what the app should already have validated. The API is part of the same scope.

What is OWASP MASVS and what level do we need?

It's OWASP's mobile application security verification standard, organised into eight categories: storage, cryptography, authentication, network, platform, code, resilience and privacy. Since version 2 it no longer defines L1 and L2 levels within the standard: scope is tuned with the OWASP MAS project's testing profiles according to the app's risk, and we agree it with you in the proposal.

Does the assessment help with GDPR compliance?

Yes. We identify where personal data is stored and transmitted, whether it is properly protected and which permissions are unnecessary. That information is key to the data protection impact assessment (DPIA) and to making sure the Google Play data safety section tells the truth.

How long does an Android app pentest take?

It depends on the number of features and roles and whether the API is in scope. The technical phase of a pentest usually takes 3 to 10 business days and the report arrives 2-3 days later; the exact timeline is set in the proposal.

Mobile platforms

The app's backend

For product teams

Sources

Ready to protect your business?

Answer the scoping form at your own pace and we'll use it to prepare your proposal. If you'd rather talk first, book a free 30-minute call.

Scope your project · Request an Android assessment