Android Security Assessment (MSTG)
Android application security assessment following OWASP MSTG
Our Android Application Security Assessment is a broad review of an Android app guided by the OWASP MASVS and its testing companion, the OWASP MASTG. We test the app from several angles: the data it keeps on the device (SharedPreferences, the SQLite database, files, and caches), how it encrypts data and stores keys, the components it exposes to other apps (activities, services, broadcast receivers, and content providers) and the inter-process communication that flows through intents, the security of its network traffic and certificate handling, and how well it resists reverse engineering and tampering. A device is easily lost, shared, or rooted, so the app has to hold up when the platform around it is not trusted. We carry every finding through to a working proof, rate it with CVSS alongside its real impact, and write it up with a concrete fix.
What's Included
Local data storage: SharedPreferences, the SQLite database, files, external storage, logs, and caches
Cryptography and key management, including use of the Android Keystore
Exported components — activities, services, broadcast receivers, and content providers — and their permissions
Inter-process communication through intents, deep links, and pending intents
Authentication, session handling, and token storage on the device
Network communication, TLS configuration, and certificate validation and pinning
The network security configuration, WebView settings, and use of platform APIs
Reverse engineering and tampering resistance: obfuscation, root and debugger detection, and repackaging
Client-side secrets and sensitive logic exposed in the APK
Privacy: what data leaves the device, to whom, and with what consent
How It Works
- Executive summary with a risk overview for decision-makers
- Detailed technical report, each finding with a reproducible proof of concept
- Findings mapped to the OWASP MASVS categories
- Storage, cryptography, and key-management findings specific to the device
- Exported-component, IPC, and network-communication findings
- Reverse-engineering and resilience assessment scoped to the app's risk
- CVSS severity and business impact for every finding
- Prioritized remediation roadmap and re-testing after remediation
Why HafezSecure
Frequently Asked Questions
It is a broad security review of an Android app guided by the OWASP MASVS and MASTG. It covers local data storage, cryptography and key management, exported components and IPC, network communication, use of platform APIs, and resistance to reverse engineering — with every finding proven and rated.
The MASVS verification service checks an app against a chosen MASVS assurance level and reports coverage against that standard. This assessment is the broad hands-on test underneath it: we exercise the app across storage, platform, network, and resilience to find real, exploitable issues. Many teams run this first and use verification when they need a level attested.
At a minimum, a build of the app we can install and test accounts for each user role. For deeper coverage we ask for the source or a debuggable build, and documentation of the backend. We agree the depth — black, grey, or white-box — before we begin.
This assessment focuses on the app on the device and the security of its communication. If you want the backend API tested end-to-end alongside the app, our combined mobile and API assessment covers both and the integration between them.
We prefer a staging backend with representative data so production users and records are never affected. Where a test must run against production, we agree the limits in advance and avoid any destructive action.
It can be. A device is lost, shared, backed up, or rooted, and data written in the clear — in preferences, the database, logs, or external storage — becomes readable to another app or to whoever holds the device. We check what is stored, whether it needs to be, and whether it is protected.
Each finding gets a CVSS score for a common baseline, adjusted by the real impact in your app — what an attacker reaches, how easily, and what data or accounts are at risk. That is why two issues with the same CVSS can be prioritized differently.
No. We test the build you give us, whether it is published, in internal testing, or a release candidate. Testing before release is usually the better time, because the fixes land before your users do.
Yes — after you remediate, we re-test the reported findings to confirm each fix holds. Duration depends on the size and complexity of the app, and we give a firm estimate after scoping.
Related Services
Complementary services that might be useful for you