Android Security Assessment (MSTG)

Android application security assessment following OWASP MSTG

About This Service

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

1
Scoping & Access
We agree the boundary and set the test depth: black-box from the APK alone, grey-box with test accounts and documentation, or white-box with source access for the deepest coverage. We ask for a build we can test, test accounts for each role, and a note of any backend that should stay out of scope. Testing usually runs against a staging backend so production data and users are never touched.
2
Static Analysis & Storage
We unpack the APK and review the manifest, exported components, permissions, and the network security configuration. We run the app and inspect what it writes to storage — preferences, the database, files, logs, and caches — and whether anything sensitive is left in the clear, on external storage, or in a backup.
3
Dynamic & Platform Testing
We test the running app: authentication and session handling, the crypto and key storage, and the exported components and intents that other apps can reach. We intercept network traffic to check TLS, certificate validation, and pinning, and we probe deep links, WebViews, and the platform APIs the app relies on.
4
Reverse Engineering & Resilience
We reverse the app to see what a motivated attacker sees: secrets and logic left in the code, and how well the app resists tampering, repackaging, and running on a rooted or hooked device. The right level of resilience depends on what the app protects, and we scope it to that.
5
Validation, Reporting & Re-testing
Every finding is verified with a reproducible proof of concept, mapped to the MASVS category it belongs to, rated with CVSS and the real business impact, and written up with a prioritized fix. After you remediate, we re-test to confirm the fixes hold.
Deliverables
  • 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

Standards-based Coverage
The assessment follows the OWASP MASVS and MASTG, so coverage across storage, crypto, authentication, network, platform, and resilience is explicit and checkable rather than ad hoc.
Android Platform Depth
We understand how Android isolates apps, how components and intents expose an app to others, and how the Keystore protects keys, so we find the platform risks a generic scanner misses.
Reverse Engineering Skill
We look at the app the way a motivated attacker does — decompiling, hooking, and running it on a rooted device — to test the secrets and defenses that only show under real pressure.
Actionable, Prioritized Findings
Clear guidance prioritized by risk, with a reproducible proof of concept and a concrete fix for every finding.

Frequently Asked Questions

What is an Android Application Security Assessment?

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.

How is this different from your MASVS verification service?

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.

What access and materials do you need?

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.

Do you test the backend API too?

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.

Do you test against production or staging?

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.

Is insecure local storage really a risk if the phone is locked?

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.

How is the severity of findings decided?

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.

Do you need the app published on the Play Store?

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.

Is re-testing after remediation included?

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.

Ready to Get Started?
Contact our team to discuss your security assessment needs