Android app security testing against MASVS

Why teams commission Android app security testing

Teams usually commission Android app security testing when a Google Play launch, a customer security questionnaire, a compliance requirement, an insurer or a due diligence request puts a question on the table that the team cannot answer from its own records. Android app security testing is a structured, scoped assessment of an Android app and the components around it, checked against the OWASP Mobile Application Security Verification Standard (MASVS) and the procedures in the OWASP Mobile Application Security Testing Guide (MASTG). The output is a documented record of what was tested, what was found and what was fixed, which is evidence for the people asking the question.

*MASVS* defines the security requirements, grouped into control areas such as MASVS-STORAGE, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE and MASVS-RESILIENCE. *MASTG* explains how an assessor tests each requirement on Android. The testing targets the risks that most often matter for Android apps: sensitive data left in local storage or logs, weak trust in network connections, exported components that other apps can invoke in unintended ways, and code protection that does not match the value of what the app contains. Ask the provider which MASVS version and profile (L1, L2 or R) they will test against, and confirm the Android version and device set they will use.

A test report is evidence of testing, not a certification. No standard body or DeployOpen issues an Android app certificate on the strength of a test, and the scope and depth of the work determine what the report can support. Before you commission a test, confirm with the party asking for it (your customer, auditor, insurer or Google Play review team) which profile they expect and whether they will accept a report from an independent assessor. Google's Mobile Application Security Assessment (MASA) is a separate, review-based program, and its limits are covered in the section on Play Data safety.

What can be in scope for an Android app test

An Android test is only as useful as its boundaries. The decisions below set which builds, controls, devices, accounts and backend components the work covers, and they should be written into the statement of work before testing starts.

APK or AAB builds and versions

Name the exact build under test, including the application ID, version code and version name, and whether the artifact is a release APK or an AAB that Google Play later splits into device-specific APKs. Testing a debug build can miss protections that only ship in release builds, such as minification, signing configuration and disabled debugging. Ask the client to supply the build and its checksum, and agree whether a later build will be retested.

MASVS profile: L1, L2 or R

Choose the verification level first, because it decides which requirements apply. L1 covers basic security requirements for most apps, L2 adds advanced controls for apps handling sensitive data, and R adds resilience against reverse engineering and tampering. Confirm with the client's compliance owner which level their framework or customer expects, and record any requirement that is out of scope with a reason.

Devices and OS versions

Decide which Android versions, API levels, device manufacturers and form factors the test covers. Storage, keystore and permission behavior can differ between releases and vendor builds, so a test on a single emulator may not represent the user base. Ask the client for the minimum supported Android version and the top devices in their analytics, and agree whether rooted or emulated devices are part of the test.

Test accounts and roles

List every user role the app supports, such as guest, standard customer, administrator or delegated agent, and provide a test account for each. Authorization flaws usually appear when one role reaches another role's data, so each account needs realistic data on it. Confirm who creates and removes these accounts, whether they can use real payment or identity methods, and how the client will receive credentials.

Backend APIs included or tested separately

Decide whether the APIs the app calls are inside this engagement or in a separate web and API test. Including them lets the tester follow a token from the app into the backend, which is where most serious mobile findings sit. If they are tested separately, agree the endpoints, the environment and how findings that span both will be assigned and reported.

Rules of engagement and environments

Set the environment, the time windows, the request rate limits and the production restrictions in writing. Most engagements use a staging environment that mirrors production, and any test against live customer data needs explicit approval, data handling terms and a stop procedure. Agree who the testers contact when a finding looks like an active incident.

How an Android app test runs, phase by phase

The sequence moves from agreed scope and a chosen MASVS profile through static and dynamic analysis to a severity-rated report and a retest of fixed findings. Each phase produces an artifact the client can check against its own requirements.

Agree scope against a MASVS profile
The provider and client agree in writing which MASVS control groups apply and whether the test targets L1, L2 or R, based on the app's data and threat model. The client confirms the app version, build type, test accounts, backend environments and any out-of-scope features. The step closes when the scope document lists the profile, the Android builds in scope and the testing window. Confirm with the provider whether MASVS-PRIVACY is included, since it was introduced in MASVS v2.1.0.
Collect and prepare the test package
The client supplies the release or debug-signed APK or App Bundle output, along with any build variant that differs from production. The tester confirms the package version, signing details and build flags so findings map to the exact binary. The step closes with a recorded inventory of the package and the test devices or emulators used. Ask whether the client can provide a build with the same configuration as production, because some protections change behavior in debug builds.
Run static analysis of the package
The tester reviews the decompiled and unpacked app for hardcoded secrets, insecure storage declarations, exported components in the manifest, backup settings, embedded keys and third-party libraries. Procedures follow the MASTG Android tests for each control, and results are compared against the weakness categories in MASWE. The step closes with a list of candidate issues, each tagged with a MASWE or MASVS reference, that feeds the dynamic phase.
Test behavior on devices
On instrumented devices or emulators, the tester exercises authentication, session handling, local storage, clipboard and logging behavior, and intent-based interactions with exported components. Network traffic is observed through a proxy configured with the client's permission. The step closes when each candidate from static analysis is confirmed, ruled out, or marked as needing client input, with the reproduction conditions recorded.
Check network and platform configuration
The tester reviews the network security configuration, certificate pinning where it is claimed, TLS settings, cleartext permissions and the handling of tokens between the app and its backend. Platform checks cover permissions requested, WebView configuration, deep links and inter-app communication. Where backend APIs are in scope, they are tested under the separate mobile backend API process. The step closes with a documented result for each MASVS-NETWORK and MASVS-PLATFORM control in scope.
Assess resilience where required
If the profile includes R, or the client has asked for protection against reverse engineering and tampering, the tester evaluates root and emulator detection, debugger checks, integrity validation and code obfuscation against the MASVS-RESILIENCE controls. Protections are judged by how much effort they add for an attacker, not by whether they exist. The step closes with a statement of which resilience controls are met, partly met or absent, and what the client must decide about acceptable risk.
Deliver a rated report with MASVS references
The provider issues a report that lists each finding with its severity, affected component, reproduction notes, a MASVS control and MASTG test reference, and a recommended fix. A summary table shows which controls passed, failed or were not tested. The step closes when the client accepts the report and confirms which findings it will remediate. Ask the provider how severity is assigned and whether the report format suits your auditor or the Play Data safety review.
Retest fixed findings
After the client ships corrected builds, the tester repeats the original procedure for each finding marked as fixed and records whether the issue is resolved, partly resolved or still present. Retest results are added to the report as a dated addendum that references the original finding IDs. The step closes when every finding has a retest status. Confirm whether retest is included in the original scope or quoted separately.

How exported components, storage and network configuration get tested

A tester starts with the AndroidManifest.xml and the build output, because the manifest declares every activity, service, broadcast receiver and content provider the app exposes to other apps on the device. Any component marked as exported, or one that carries an intent filter and therefore is exported by default on older target levels, becomes an entry point that a malicious app could call. For each one, the tester records whether it needs a permission, whether the data it accepts is validated, and whether it can be reached with extras that change its behavior. The evidence is the manifest excerpt, a component inventory with a justification for each exported entry, and a note on the minimum and target SDK values that set the defaults. Before testing starts, the client should confirm the build variants in scope, since debug flags and extra components often differ from the release build that users install.

Storage and backup review follows the same logic on disk. The tester checks which directories hold preferences, databases, caches and files under the app's private storage, whether sensitive values sit in plain form or in the Android Keystore-backed options the platform provides, and whether logs, temporary files or screenshots keep copies of account data. Backup behavior is a separate question: the manifest's backup settings and any data extraction rules determine what leaves the device through cloud or device-to-device backup. For network configuration, the tester reviews the network security configuration file, cleartext traffic permissions, trust anchors, and whether certificate pinning, where used, has a documented fallback and rotation plan. The output is a finding list tied to MASVS-STORAGE and MASVS-NETWORK controls, with the file path, setting and a device-side observation for each item.

Platform interaction covers the places where app data crosses a boundary it does not control. WebViews need a review of JavaScript enablement, file and content access, and which URLs the app loads and bridges to native code. Clipboard use, keyboard caching, autofill, and app switcher snapshots can all retain credentials or personal data beyond the screen where they appear. Logging is checked in both debug and release builds, because verbose output from a crash handler or analytics library can persist identifiers outside the app. The tester records the code path, the data class involved and whether the exposure is reachable by another app or only by someone holding the device. Clients should confirm in advance whether test devices, accounts and a rooted or instrumented device are permitted, since several of these checks depend on them.

Weakness categories in Android apps and why they matter

This table maps the Android weakness categories a test typically examines to their MASVS control group, what the weakness looks like in an app, and the business impact if it is exploited. Read each row as a question to ask your own app team: if the answer is unclear, the category is worth testing first.

Weakness category	What it looks like in an Android app	Why it matters to the business
STORAGE (MASVS-STORAGE)	Session tokens, personal data or secrets kept in shared preferences, SQLite databases, external storage or logs readable by other apps or by someone with device access	Account takeover and personal data exposure after a lost or shared device, plus regulatory scrutiny over data at rest
CRYPTO (MASVS-CRYPTO)	Custom or deprecated cryptographic routines, weak key handling, or keys generated and stored in ways that let them be extracted	Encrypted data offers little protection if keys can be recovered, which undermines customer and auditor assurances
AUTH (MASVS-AUTH)	Weak local authentication checks, biometric prompts that can be bypassed in the app logic, or tokens that do not expire or rotate correctly	Unauthorized access to accounts and transactions, and disputes over whether the app enforced strong authentication
NETWORK (MASVS-NETWORK)	Cleartext traffic permitted in the network security configuration, weak TLS settings, or missing certificate validation for backend endpoints	Exposure of credentials and personal data in transit, especially on public or untrusted Wi-Fi networks
PLATFORM (MASVS-PLATFORM)	Exported activities, services, broadcast receivers or content providers without permission checks, deep links that trigger sensitive actions, or insecure WebView settings such as JavaScript bridges to untrusted content	Other apps on the device can trigger privileged functions or read data, and a malicious link can lead to account actions
CODE (MASVS-CODE)	Outdated dependencies with known flaws, debuggable release builds, hardcoded API keys or secrets in the APK, or missing input validation on intents	Leaked keys can be abused against paid services or backends, and vulnerable libraries inherit their flaws into every release
RESILIENCE (MASVS-RESILIENCE)	Missing or weak root, emulator or tamper detection where the app handles high-value operations, and easy repackaging or hooking of sensitive logic	Relevant mainly for apps that need protection against reverse engineering; a cloned or modified app can be used for fraud
PRIVACY (MASVS-PRIVACY)	Sensitive identifiers sent to third-party SDKs without need, data collection that differs from what the app discloses, or no user control over personal data	Inaccurate Data safety declarations and privacy complaints, and a weaker position when a reviewer asks how data is minimized

How a MASVS L1 test relates to Google's MASA review

Google's Mobile Application Security Assessment (MASA) is a separate review from a DeployOpen test, and the two should not be treated as interchangeable. MASA is run through the App Defense Alliance, where authorized lab partners validate apps against MASVS Level 1 requirements using the MASTG. Developers who complete the review can show the independent security review in the Data safety section of their Google Play listing. A DeployOpen test of an Android app can be scoped to the same MASVS L1 controls and the same MASTG Android tests, so the technical work overlaps, but DeployOpen does not perform the MASA review and does not issue Google's review or its listing evidence. Confirm current MASA eligibility, lab requirements and listing rules directly with the App Defense Alliance before you plan around them.

The App Defense Alliance states that MASA reviews are limited in nature and do not guarantee complete safety. A review therefore covers what the lab tests within its agreed approach, not every exported component, storage location or network setting in your build. Developers also remain responsible for accurate Data safety declarations. If your app collects, shares or deletes data in ways the listing does not describe, a clean review does not correct that. Before commissioning any test, compare the MASVS L1 controls in scope with what your Data safety form says about data collection and sharing, and ask your privacy or legal lead to own that comparison.

When you scope a DeployOpen test, ask for a written mapping of each MASVS L1 control and MASTG test to the app version, build type and test accounts you will provide. Ask which findings would count as blocking for your release, and how retesting after fixes is recorded. Keep the report, the mapping and the Play Console declarations together so an auditor, a customer or a Google reviewer can see what was tested, by whom, against which build and with what result. If you intend to show independent review in your listing, plan the MASA process as its own step with its own lab, and keep the DeployOpen report as supporting evidence of the test you commissioned.

Which frameworks and customer reviews ask for Android app testing

This table compares the frameworks, store reviews and customer questionnaires that commonly expect Android app testing, what each one looks for, and what to confirm before scoping. Use it to match your obligation to a test profile and to check the evidence your auditor or customer will accept. The main takeaway is that MASVS provides the test basis, but a Play Data safety disclosure, a customer questionnaire and a sector framework each ask for different evidence.

Framework or review	What it expects	What to confirm first
OWASP MASVS (basis for testing)	Verification of requirements grouped into storage, crypto, authentication, network, platform, code, resilience and privacy control groups, at a chosen level	Which profile (L1, L2 or R) your auditor or customer accepts and which control groups are in scope
Google Play MASA via App Defense Alliance	An independent review by an authorized lab against MASVS Level 1 using the MASTG, which developers can reference in the Data safety section	Whether your app qualifies for the program and that the review is limited, so Data safety declarations remain your responsibility
Customer security questionnaires	Evidence that the Android app and its backend APIs were tested, often with a summary report and remediation status	Whether the customer wants a named standard, a report date window, retest evidence or a summary only
Sector frameworks for mobile access to sensitive data	Assurance that mobile channels to financial, health or personal data are verified, including authentication and storage controls	Which control set applies, whether the auditor accepts MASVS mapping, and how the mobile channel is named in scope
CREST OVS accredited assessments	Assessment by a provider accredited to OWASP Verification Standard for mobile at Levels 1 and 2	Whether the customer or assessor requires an accredited provider and which level they expect
Internal security governance and insurer reviews	Documented test coverage of the app and the APIs it calls before release or renewal	Whether the review covers the backend, the release build and the retest window they require

What the client receives and whether it satisfies a customer or auditor

An Android test produces a set of documents, and each one serves a different reader: the security team, the developers, the customer's security reviewer or the auditor. Whether the package is enough depends on what the recipient asked for before work started, so confirm acceptance criteria in writing first. The cards below cover what arrives, how it maps to MASVS and MASTG, and where its limits lie.

Executive summary and scope profile

The executive summary states what was tested, the app version and build identifiers, the testing profile (L1, L2 or R) and the overall risk picture in plain language for non-specialist leaders. The scope profile records which Android components, backend endpoints, accounts and devices were in play, and which were excluded. Check that the profile matches what your customer or regulator asked for, because a report that tested only L1 will not answer a request framed around L2 controls.

Method and test coverage record

The method section explains the test approach, the tools and MASTG test procedures used, the Android versions and devices covered, and any tests that could not be run. Coverage gaps are the part most often questioned by auditors, so the report should list them explicitly with the reason, such as a control that depended on a server-side component outside scope. Ask the provider to map each control group, from STORAGE through PRIVACY, to the tests executed or to a stated reason for not testing it.

Findings with severity and MASVS references

Each finding should name the affected Android component or behavior, its severity, the MASVS control and, where the provider uses it, the MASWE weakness identifier that describes the underlying defect. Good findings also state the business impact in the context of your app and the data it holds. Ask whether the severity scale is documented and whether it is applied the same way across findings, since reviewers compare these ratings across vendors.

Defensive reproduction notes

Reproduction notes describe how a weakness was confirmed at a level your developers can act on, such as which configuration was inspected or which response showed the defect. They should not contain working exploit code, payloads or step-by-step attack instructions, and a report that does is a handling risk in its own right. Ask the provider how the report is stored, who receives it and how access is limited for the duration of the engagement.

Remediation guidance and retest results

Remediation guidance gives developers a specific fix for each finding, such as changing a manifest attribute, moving a secret out of app storage or tightening server-side authorization. Retesting checks that the fixes work, and the retest report records each finding as resolved, partially resolved or open. Confirm whether retesting is included in the fixed-scope quote, how many retest rounds are covered and the window in which retest must be requested.

Summary letter and use with auditors

A summary letter is a short statement from the provider describing the engagement scope and dates and the overall outcome, which you may share with a customer or Play Console reviewer. DeployOpen does not issue audit reports, attestations or certifications, and a summary letter from a testing provider is not an assurance opinion. Agree the letter's wording and recipients before work begins. Confirm with the customer or auditor whether they accept a full technical report, a summary or both, and whether they require a specific accredited provider.

How Android testing differs by app architecture

Native apps written in Kotlin or Java compile to Android bytecode and run directly on the platform APIs, so the tester works with the manifest, components, storage and network configuration as Android exposes them. Static work centers on the decompiled or source-level review of the manifest, exported activities, services, broadcast receivers and content providers, along with how the app stores data and handles certificates. Dynamic work focuses on runtime behavior on a test device, including how intents are handled and what traffic leaves the app.

Manifest and components: Review exported components, intent filters, permissions and backup settings against the MASTG Android tests.
Local storage: Check shared preferences, databases, files and the Android Keystore use for sensitive data at rest.
Network configuration: Review the network security configuration, certificate pinning decisions and cleartext traffic rules.
Build artifacts: Confirm whether the tester receives release or debug builds, since obfuscation and debug flags change what is visible.
Client inputs: Provide release builds, test accounts with defined roles, a documented list of exported components and access to a test device.

Before testing, ask the client which build types are in scope and whether a debuggable build is acceptable for the test.

What to prepare before an Android test starts

Agree the build set and access in writing before the test window opens, because a scope document that names a build the tester cannot install or an account that does not work will push the timeline out before any testing begins. For an Android app, the client should provide the release build under test, and where the scope calls for it, a debug-capable build or a build with a documented configuration that lets the tester inspect the app. Confirm which package name, version code and signing certificate each build carries, since the tester will need to match findings to a specific artifact. If the app is delivered through a managed track, confirm whether the test build comes from an internal testing track or from a sideloaded APK, and whether the client will supply the APK file directly.

Provide one test account for each role the app supports, such as a standard user, an administrator and a user with limited entitlements, along with seeded records that give each role something to read and change. Name a technical contact who can answer questions about the backend, reset accounts, and approve any testing against shared environments. Confirm device or emulator access as well: the scope should state which Android versions and device types are covered, and whether the client will lend hardware or expects the tester to bring it. Set change freeze windows so that a backend deployment does not invalidate tokens or alter endpoints in the middle of the test.

What to check before choosing an Android testing provider

Choosing a provider for Android app security testing comes down to whether their method, credentials, report and commercial terms can be checked before work starts. The cards below cover the questions that separate a verifiable engagement from a generic scan with a MASVS label. Ask for written answers to each one before you sign.

Evidence of MASVS and MASTG method

Ask the provider to show how each test case maps to a MASVS control and to a MASTG test for Android. A credible method names the control group, the testing profile (L1, L2 or R) and the procedure used for each requirement. Be wary of proposals that only say the app was tested against MASVS without listing which requirements were in scope and which were excluded.

CREST OVS accreditation status

Ask whether the provider holds CREST's OWASP Verification Standard accreditation for mobile assessments against MASVS Levels 1 and 2. CREST announced the first accredited companies on 28 October 2022. Confirm the accreditation directly with CREST and check that it covers the Android work you are buying, not only web testing.

Sample report structure

Request a redacted sample report before commissioning the test. Look for a per-finding record with the MASVS control, a reproduction path that a developer can follow, severity with the reasoning behind it, and a clear statement of which requirements passed, failed or were not tested. A sample that reads as a list of tool output will be hard to use with an auditor or a customer's security team.

Retest terms

Confirm in writing whether one retest of fixed findings is included, how long after the report it can be requested, and whether retest evidence is issued in the same format as the original report. Retesting is where most disputes arise, so agree the window and the fixed build that will be tested before work starts.

Tester qualifications

Ask who will perform the Android work and what they have done on Android specifically, including reverse engineering of compiled apps and manifest review. Confirm whether named testers hold recognized individual certifications and whether the same people will review your builds. A firm's general reputation does not show who is reading your code and manifest.

Data handling and the written scope

Ask how the provider stores builds, test accounts, tokens and captured traffic, how long they keep them and how they delete them at the end of the engagement. Confirm that the quote follows a written scope listing the app versions, environments, accounts and MASVS profile, so that pricing and effort can be traced back to specific work.

Common questions about Android app security testing

How much does an Android app security test cost?

The price follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of app versions and build variants to test, the MASVS levels requested (L1, L2 or R), how many MASVS control groups are in scope, whether the backend APIs are included, and how much reverse engineering or tampering work the resilience controls require. Ask for a quote that separates the initial assessment from any retest, and check whether each item is one-time or recurring, such as a retainer for continuous testing. A quote should name the deliverables, the test builds and the accounts the client provides.

How long does an Android app penetration test take?

Duration depends on the size of the app, the MASVS level, the number of MASTG Android tests selected, and how quickly the client provides builds, test accounts and access to the backend environment. Resilience testing (MASVS-RESILIENCE) and API testing usually add work. The written scope and timeline should state the start date, the testing window, the reporting date and any dependency on client responses. Ask the provider to show how it handles delays so the schedule is clear before work starts.

What does the client need to provide for an Android test?

Plan to supply a debug or release-like build that matches production, the signed build artifacts for each version in scope, test accounts with the roles the app supports, and a staging or test environment where possible. Provide the backend API documentation or specification, details of third-party SDKs, and a named contact who can answer questions during testing. For MASVS-PRIVACY and Data safety work, the client should also share its privacy policy and the list of data the app collects. Confirm each item in the written scope so the testing window is not lost to access problems.

Can our internal team run this test without an outside provider?

Internal teams can run MASTG-based checks, and many do so as part of their development process. An independent test is different because the reviewer is not the developer who built the app, which matters when a customer, regulator or auditor asks for third-party evidence. Ask whether your team has skills in static analysis, dynamic analysis, network interception and reverse engineering on Android, and whether it can document results against MASVS control IDs. A mixed model, where internal teams run routine checks and an outside provider performs the formal assessment, is common.

Does a Google MASA review replace a MASVS Level 1 test?

No. Google's Mobile Application Security Assessment (MASA), run through the App Defense Alliance, uses authorized lab partners to validate apps against MASVS Level 1 using the MASTG, and developers can show the review in the Data safety section of their Play listing. The App Defense Alliance states that MASA reviews are limited in nature and do not guarantee complete safety, and developers remain responsible for accurate Data safety declarations. A privately commissioned MASVS L1 test can help prepare for MASA, but it does not give you the MASA review itself. Confirm the current MASA requirements directly with the App Defense Alliance before you plan around them.

Do the backend APIs need to be tested too?

Yes, in most cases. Mobile backends are usually APIs, and serious findings often sit there rather than in the app binary. Object and function level authorization, token handling with OAuth and OIDC, and API abuse should be measured against the OWASP API Security Top 10 2023 and OWASP ASVS V4. An app test that does not cover the APIs it calls can leave the most important controls untested. Decide with your provider whether the backend is in the same engagement or in a separate API test, and confirm which endpoints and environments are in scope.

How does retesting work after the findings are fixed?

Retesting checks whether the fixes resolve the findings from the original report. Scope it in advance: state how many findings are covered, which app versions will be tested, and whether retest work is included in the original quote or priced separately. Ask the provider to report each finding as resolved, partially resolved or open, with the evidence used. Because a new build can change behavior, retesting should use the build you release, and any later release may need its own check.

How DeployOpen scopes, tests, reports and retests Android apps

DeployOpen approaches Android app security testing as a fixed-scope engagement agreed in writing before work starts. The test is aligned to the OWASP MASVS and the MASTG Android tests, and the client receives documentation that can be used with their own auditors, customers or Google Play review process.

How we scope

Agree in writing which app versions, Android components and MASVS control groups the test covers
Confirm the target profile, L1, L2 or R, and whether MASVS-PRIVACY checks support the Play Data safety declaration
Define which backend APIs, environments and test accounts are in scope and who provides them

How we build

Request test builds, debuggable or instrumented variants, and test devices from the client before testing begins
Map each in-scope MASVS requirement to the matching MASTG Android test procedure and record the test plan
Review exported components, local storage, network security configuration and code protections against the agreed profile

How we hand over

Deliver a report that lists each finding with its MASVS or MASWE reference, affected component, evidence and remediation advice
State clearly which MASVS requirements were tested, which were not, and the limits of the assessment
Provide a retest scope for confirming fixes, so the client can show closure to auditors or customers

How we support

Offer a retest against the same requirements once the client has fixed the reported issues
Make ongoing support, upgrades and continuous testing available as a retainer after the initial engagement
Confirm with the client's compliance or release team how the report will be used before the scope is signed