Android Application Penetration Testing Report — Sample

An Android application penetration test is an authorized, hands-on security assessment in which testers combine static analysis of the application package, dynamic analysis on physical and emulated devices, and direct testing of the mobile-facing backend API to identify and manually validate exploitable weaknesses — going beyond automated scanning to confirm what is actually exploitable, how a weakness manifests on-device versus server-side, and what it means for the business. The result is a report that gives mobile engineering and security leadership a prioritized, evidence-based roadmap for remediation.

This sample report shows how TMG Security structures that deliverable for a native Android engagement. It is built around NovaSphere Pay, a fictional peer-to-peer and bill-pay mobile payments application (package com.novasphere.pay) operated by NovaSphere Digital Technologies, Inc., a fictional organization, and covers a simulated assessment window of 03–28 August 2026.

The fictional NovaSphere Pay Android client is built against target SDK 35 (Android 15) with a minimum supported SDK of 26 (Android 8.0), compiled at SDK level 35, and distributed as a single APK supporting the arm64-v8a and armeabi-v7a ABIs (APK Signature Scheme v2 + v3, fictional production certificate). The release build under test — NovaSpherePay-release-6.4.2.apk (version 6.4.2, version code 6402, ~38.6 MB compressed) — declares 18 Android components (11 exported), bundles six third-party SDKs (core payments networking, mapping/geolocation, analytics/product telemetry, crash reporting, push notification, and a local Room-based database ORM), and talks to two fictional, non-resolving backend hosts: a primary payments API and a dedicated authentication service.

Testing was strictly non-destructive and used only the dedicated fictional test accounts and devices listed in Appendix I of the full report — three fictional test devices (a rooted emulator, a non-rooted physical reference device, and a rooted physical legacy-OS reference device) plus an isolated interception-proxy host, and no real user accounts, signing keys, or customer data were used at any point.

TMG Security's Android testing approach is conceptually informed by the OWASP Mobile Application Security Verification Standard (MASVS), the OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, and the OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0. Every MASVS control, MASWE weakness identifier, and MASTG test case referenced in this report is drawn from current, publicly verifiable OWASP mobile application security material; where a precise identifier could not be confidently mapped to a specific finding, this report describes the testing concept in narrative terms rather than presenting an invented identifier.

TMG Security is not affiliated with, endorsed by, or certified by OWASP. This report is not an OWASP-certified assessment, an official OWASP audit, or evidence of any OWASP accreditation, and no copyrighted OWASP material is reproduced in this document — the frameworks above are cited only as conceptual, methodological grounding for TMG's own independent testing approach.

Testing covered eight MASVS control groups spanning 24 individual MASVS controls: storage, cryptography, authentication, network communication, platform interaction, code quality, resilience, and privacy. The methodology combined static analysis of the decompiled application, dynamic analysis on rooted and non-rooted fictional test devices, mobile-API integration testing against the backend directly, IPC and component security review, and dedicated resilience and privacy assessment — a ten-stage program executed against 155 individual test cases (Appendix A of the full report), with every candidate finding manually validated by a TMG Security fictional tester before inclusion.

Once an Android application is installed, its APK, local storage, and runtime behavior are all within reach of whoever controls the device — which changes what the application can safely treat as a trust boundary. Anything checked only on the client, whether a permission gate on an exported component, a client-side signature check, or a boolean flag set after a biometric prompt, is a user-experience feature rather than a security control: on a rooted or instrumented device, that check can be bypassed entirely, and any other app installed on the same device can attempt to interact with it directly through Android's own inter-process communication mechanisms.

NovaSphere Pay's own trust boundary sits at three points repeated throughout this report: the boundary between the app's private sandbox and the rest of the device (governed by storage protection, backup configuration, and IPC/component export settings); the boundary between the app and other installed applications (governed by exported-component permissions, deep-link validation, and WebView JavaScript-bridge scoping); and the boundary between the mobile client and its backend API (governed by whether the server independently re-verifies every authorization decision the client believes it has already made). The most severe findings in this assessment — AND-001 through AND-004 — each sit directly on one of these three boundaries.

TMG Security decompiled the fictional release APK and reviewed AndroidManifest.xml, the full requested-permission set, declared components, build configuration, and third-party SDK inventory, then reviewed the decompiled source for hardcoded secrets, API keys, debug artifacts, and insecure coding patterns. Static review confirmed android:debuggable is correctly false in the release manifest merge, but found a hardcoded third-party mapping-SDK API key in strings.xml, a hidden pre-production debug menu reachable via a version-label tap sequence in the QA build flavor, and identifier obfuscation applied inconsistently — the core banking and payments modules are fully obfuscated, but two integration modules retain fully readable class and method names. Manifest review separately confirmed android:allowBackup="true" with no compensating backup-rules exclusion, and 11 of 18 declared components exported, a subset of which lack a corresponding permission or caller-identity check.

TMG Security reviewed NovaSphere Pay's full inter-process communication surface — every exported Activity, Service, Broadcast Receiver, and Content Provider — assessing whether each exported component serves a documented cross-app integration need and whether it independently validates the caller and the Intent it receives, rather than assuming only the app's own UI can reach it. Of the 11 exported components, the funds-transfer service and the payee deep-link activity were confirmed to accept privileged actions from any co-installed application with no caller-identity or confirmation check; the app's FileProvider grants a broader-than-necessary path scope for its statement-export feature; a task-affinity/launch-mode configuration on the MFA-verification activity creates a task-hijacking risk consistent with StrandHogg-style attacks; and a low-sensitivity FAQ content provider is exported without any functional cross-app requirement. TMG Security additionally flags the overall exported-component count itself as a hardening opportunity independent of any single confirmed weakness.

TMG Security tested NovaSphere Pay's custom-scheme deep link (novasphere://) and its equivalent HTTPS App Link for sensitive account-modifying actions reachable without in-app confirmation, general intent-handling for spoofing/task-hijacking risk, and the in-app support WebView's JavaScript-bridge exposure and navigation scoping. The payee-addition deep link commits a new, attacker-controlled payee to the authenticated user's account immediately on link open, with no confirmation screen or step-up authentication, meaning a crafted link delivered via SMS, email, or a compromised webpage can silently stage a follow-on social-engineering-driven transfer. Separately, the support WebView exposes a native JavaScript interface (NovaBridge) with methods including getSessionToken() and getDeviceId(), with no origin verification on the calling page and mixed-content loading left enabled — meaning any content the WebView can be coerced into loading, including a first-party redirect abused by an attacker, could call the bridge and retrieve the live session token.

TMG Security inspected every form of on-device persistence NovaSphere Pay uses for sensitive data: SharedPreferences, the Room/SQLite local database, the HTTP response cache, screenshot/Recent-Apps thumbnail capture, the system clipboard, and Android's backup/restore mechanism. The most severe finding in this entire assessment sits here: the app's OAuth 2.0 access token, refresh token, and a device-binding secret are all persisted in cleartext inside a standard, unencrypted SharedPreferences file rather than behind an EncryptedSharedPreferences (Jetpack Security Crypto) or Android Keystore-backed envelope — recoverable directly from the app's private data directory on any rooted device or via an unpatched backup-extraction path, with no cryptographic barrier at all. The same exposure is independently reachable a second way: android:allowBackup="true" with no compensating exclusion rule means a standard adb backup extraction recovers the identical token file. Additional, lower-severity gaps were confirmed in cache handling (financial statement responses cached to disk without a no-store directive), screenshot protection (two account-balance and card-detail screens omit FLAG_SECURE), clipboard handling (a full account number copied without the sensitive-content marker), and the local Room database (transaction history stored in a standard, unencrypted SQLite file).

TMG Security reviewed NovaSphere Pay's use of cryptographic primitives, Android Keystore integration, and random-value generation for security-relevant data. Cryptographic keys used for local field-level encryption are correctly generated and held inside the Android Keystore, hardware-backed on both fictional test devices, and no custom or home-grown cryptographic implementation was identified in place of platform primitives — a genuine positive control. The one confirmed weakness is narrower: a client-side request nonce used for replay protection on a subset of mobile-API calls is generated with java.util.Random seeded from the current timestamp rather than a cryptographically secure source, making the nonce sequence predictable to an attacker with approximate timing knowledge of the request. Because this nonce supplements rather than replaces server-side replay validation, the weakness reduces defense-in-depth rather than independently enabling replay attacks.

TMG Security reviewed NovaSphere Pay's Network Security Configuration and tested TLS enforcement and certificate validation across every network client the app uses, via a fictional interception-proxy host on an isolated test network. cleartextTrafficPermitted is correctly set to false at the base configuration level with no permissive per-domain override, and the primary payments API client enforces TLS 1.2+ platform-wide with certificate pinning and no legacy-protocol fallback — a strong baseline. Two gaps were confirmed away from that primary client: a legacy telemetry/analytics network client implements a custom X509TrustManager whose checkServerTrusted() method is a no-op, so it accepts any presented certificate including a self-signed one under an adversary-in-the-middle position; and the Network Security Configuration does not explicitly pin a minimum TLS version, so a fictional test endpoint offering only TLS 1.1 still completed a handshake rather than being refused. A broader wildcard domain entry retained from a legacy CDN integration, alongside the specifically pinned production domains, was separately flagged as a configuration-hygiene gap.

TMG Security assessed NovaSphere Pay's login, session-timeout, logout/token-revocation, and biometric/local-authentication flows. Multi-factor authentication is correctly and consistently enforced for all standard login flows with no client-side bypass path identified — a genuine positive control. Two gaps were confirmed in the surrounding session lifecycle: logout clears locally stored tokens and returns the user to the login screen, but does not call the corresponding server-side token-revocation endpoint, so a previously captured refresh token remains valid and mintable for the remainder of its natural expiry window after the user believes they have logged out; and the app's 60-minute idle-session timeout is enforced only client-side by an app-level timer, while the underlying access token's own server-side expiry is materially longer, so a captured token remains usable well past the point the app's own UI would have required re-authentication. Separately, NovaSphere Pay's biometric app-unlock gate validates the authentication outcome by checking a boolean flag set in the BiometricPrompt success callback rather than requiring a Keystore-backed CryptoObject operation to succeed — on a rooted or instrumented device, the boolean flag was set directly via standard runtime-hooking techniques, bypassing the biometric prompt entirely.

Mobile-API integration testing — exercising the 27 backend endpoints NovaSphere Pay's mobile client depends on directly, independent of the app's own UI — was the single most significant category in this fictional assessment. The mobile-only account-statement endpoint accepts a client-supplied account-identifier path parameter and returns the corresponding statement data without independently verifying that the authenticated session's own account set includes the requested identifier; a fictional proxied request substituting a foreign account identifier into an authenticated mobile session returned that unrelated account's statement and transaction data instead of an authorization error. This gap is specific to the mobile-only surface — the equivalent web-channel endpoint, out of scope for this Android assessment, was not retested. Server-side object-level authorization is otherwise enforced correctly on the majority of the endpoints tested, and rate limiting and business-logic controls (transfer limits, idempotency handling, workflow-state sequencing) were confirmed to resist manipulation server-side during testing — the confirmed authorization gap is concentrated specifically in the funds-transfer-adjacent statement-retrieval workflow.

TMG Security assessed NovaSphere Pay's posture against OWASP MASVS-RESILIENCE — the set of controls intended to slow static and dynamic reverse engineering, detect tampering and repackaging, and resist execution in a rooted, emulated, or debugged environment. Consistent with MASVS's own guidance that resilience controls are explicitly defense-in-depth, no finding in this category is rated above High for that reason alone. Root detection, tamper detection (a client-side signing-certificate hash check), and repackaging detection all share the same underlying limitation: each is a purely client-side heuristic or check, and each was successfully bypassed during fictional dynamic-instrumentation testing using a standard runtime-hooking toolkit — a finding TMG Security consolidates into a single Root/Runtime Integrity Control Bypass rather than three separate findings, since a compromised device defeats all three checks identically. Obfuscation coverage is inconsistent (two integration modules remain fully readable), and Java-layer debugger detection is implemented and functions correctly, though no equivalent native-layer (JNI) check was identified. TMG Security's primary recommendation across this entire category is architectural: adopt a platform attestation service such as the Play Integrity API as the primary resilience signal, evaluated server-side, rather than relying on client-side self-checks as the sole integrity control.

TMG Security assessed NovaSphere Pay against OWASP MASVS-PRIVACY — permission minimization, handling of personally identifiable information collected during fictional account onboarding, and third-party analytics/tracking SDK behavior. PII collected during onboarding (name, government-ID fragment, date of birth) is transmitted only over the TLS-protected primary API channel and is not retained locally beyond the active onboarding session — a genuine positive control. Two gaps were confirmed: three dangerous-level permissions (contacts, phone state, and precise location) are requested unconditionally at first app run rather than contextually at the point of use for their associated optional features, with one of the three found to have no referencing code path at all; and the bundled third-party analytics SDK generates and persists its own device-scoped identifier independently of the platform-resettable Advertising ID, so a fictional user who resets their Advertising ID as a privacy signal continues to be tracked under the same underlying analytics identifier before and after the reset.

This fictional assessment identified 47 illustrative findings across NovaSphere Pay's Android client and its supporting mobile-API integration, drawn from 155 fictional test cases mapped against 24 OWASP MASVS controls across eight control groups (Appendix A–G of the full report). Every finding, severity rating, and evidence reference below is fictional and specific to this Android penetration test — none are drawn from any other TMG sample report.

The full sample PDF plots all 47 fictional findings on a likelihood-versus-impact risk heatmap: the four Critical and the highest-risk High findings cluster in the "Likely/Very High × Moderate–Very High Impact" region, the fourteen Medium findings sit in a mid-range band, and the Low and Informational findings cluster toward "Rare/Low Likelihood × Minor Impact" — a distribution that supports prioritizing the local-storage, exported-component, and mobile-API authorization findings first.

Individual findings are often most meaningful in combination. The report's three fictional composite attack-chain scenarios illustrate how a crafted deep link (AND-004) can stage an unconfirmed payee and, combined with the broken mobile-API authorization gap (AND-003), enable cross-account reconnaissance from the same attacker position; how a malicious co-installed application can enumerate NovaSphere Pay's broad exported-component footprint (AND-032) and send a crafted Intent directly to the unprotected funds-transfer service (AND-002) with no user interaction; and how a compromised or rooted device exposes the plaintext session and refresh tokens from local storage (AND-001), widened by the backup-extraction path (AND-015), with the captured refresh token remaining valid past logout (AND-011) and ultimately replayable against the same broken mobile-API authorization gap (AND-003). These are fictional composite scenarios only and must not be construed as exploit chains against any real system.

The table below maps each Critical and High fictional finding to the illustrative business dimensions it most directly affects, supporting prioritization conversations beyond pure technical severity.

The fictional sample remediation roadmap sequences all 47 findings across four phases, prioritizing the four Critical findings and the highest-risk High findings first. All dates and timelines shown are illustrative.

The full sample PDF tracks fictional management response, ownership, and validation approach for every finding in a single management action plan, ensuring each of the 47 findings appears exactly once with an owner, priority, target date, status, and validation method. TMG Security recommends a structured retest following remediation: a full retest of all four Critical findings and all nine High findings, including a fresh APK build and repeated static/dynamic analysis pass; a targeted retest of each Medium finding against its specific affected component, screen, or API endpoint; and a confirmation-only review of Low and Informational items, batched into the next general assessment cycle where full retest is not independently warranted. This retest methodology is illustrative — this report does not claim that any finding has been remediated or retested.

This fictional assessment is not intended to be entirely negative. TMG Security identified a number of controls operating effectively across NovaSphere Pay's Android client and its mobile-API integration, including multi-factor authentication enforced at login with no client-side bypass path, TLS 1.2+ enforced platform-wide on the primary API client with correctly implemented certificate pinning, Room/type-bound serialization with a strict, type-bound JSON parser avoiding generic object-deserialization risk, Android Keystore usage for local field-level encryption with hardware-backed storage on both fictional test devices, cleartext traffic correctly disabled with no permissive per-domain override, correctly enforced business-logic and transfer-limit controls resisting server-side manipulation during testing, and object-level authorization correctly enforced on the majority of endpoints tested outside the specific mobile-API gap detailed in Section 14.

The following limitations apply to this fictional sample assessment: NovaSphere Digital Technologies, Inc. and the NovaSphere Pay Android application are fictional and no real organization or mobile application was assessed; no real credentials, API keys, signing keys, or production systems were used or accessed; no real customer data was accessed at any point; no production environment or production backend was tested, only fictional test devices and a fictional controlled assessment environment are represented; no destructive testing was performed or simulated, including against the fictional funds-transfer workflow; no denial-of-service testing was performed; no real Google Play Store distribution channel, code-signing infrastructure, or app-store review process was tested or accessed; no social engineering was performed; no physical device theft or physical security testing was performed; no third-party SDK vendor's backend infrastructure was tested, SDK review was limited to the client-side integration observable within the fictional APK; testing was performed against fictional test devices (rooted and non-rooted) and a fictional emulator profile, and results do not represent an exhaustive device-fragmentation matrix; and all evidence, screenshots, adb/logcat output, decompiled excerpts, and request/response examples in this report are synthetic.

Looking to validate your own Android application's security directly? TMG Security's Mobile Application Security Testing team can scope a real Android (or iOS) penetration test built with the same structure, methodology, and reporting depth shown in this sample — static and dynamic analysis, IPC and component security, mobile-API integration testing, OWASP MASVS-aligned coverage, a full finding register, and a remediation roadmap your engineering team can execute against. TMG's offensive security practice also covers API Security Testing, Web Application Security Testing, and the broader Offensive Security & Penetration Testing program this assessment type sits within.