Mobile App Security Testing With OWASP MASVS: What We Check

Start with the answer: a sound mobile app security test follows the OWASP Mobile Application Security Verification Standard, known as MASVS. It is a free, open standard from the Open Worldwide Application Security Project that lists what a secure iOS or Android app should do. A tester works through its eight control groups, uses the companion Mobile Application Security Testing Guide for the test steps, and reports each finding against a named control. That gives you results you can repeat, compare release to release, and hand to an auditor.

Why a mobile app needs its own test

A website runs on your servers. A mobile app runs on a phone you do not control. Anyone can download it, unpack it, read what is inside and run it on a modified device. So an app has to assume the device may be hostile, while its back end has to assume the app may be faked. A general web penetration test misses much of this. Mobile testing looks at the app package, the data it leaves on the phone, the way it talks to the operating system and the server interface behind it.

The eight MASVS control groups

MASVS organizes its requirements into groups. Here is what we check in each.

• Storage: Does the app keep tokens, personal data or card details in plain files, databases, logs, screenshots, clipboard or backups? Secrets belong in the platform keystore, not in app preferences.
• Cryptography: Are modern algorithms used correctly? We look for hard-coded keys, weak random numbers, outdated ciphers and home-made schemes.
• Authentication and authorization: Is sign-in enforced on the server, not only in the screen flow? We test session expiry, token handling, biometric prompts and whether one user can reach another user's records.
• Network communication: Is all traffic encrypted with valid certificates, and does the app resist a person-in-the-middle on a hostile Wi-Fi network? Certificate pinning is reviewed where the risk justifies it.
• Platform interaction: Does the app expose screens, links, file handlers or inter-app messages that another app could abuse? We review permissions, deep links and web views.
• Code quality: Are inputs validated, third-party libraries current and error cases handled safely? Outdated libraries are a common finding.
• Resilience: Where the risk calls for it, how well does the app resist reverse engineering, tampering and running on a rooted or jailbroken device? This group is optional for many apps and essential for payments or high-value content.
• Privacy: Does the app collect only what it needs, tell users plainly, and avoid leaking identifiers to analytics or advertising libraries?

How the testing works

Testing combines static and dynamic work. Static review means unpacking the app package, reading its configuration, looking for embedded secrets and checking the libraries it ships with. Dynamic review means running the app on real test devices, watching its files and network calls, altering requests and probing the screens an ordinary user never sees. Where we have the source code, we read it as well, which finds more in less time.

The server interface gets equal attention. Many apps look secure on the phone and then trust whatever the phone sends. We test the application programming interface behind the app for broken access control, missing rate limits, weak token handling and over-sharing of data. That work often produces the most serious findings.

What you should provide

• A release build that matches what customers install, plus test accounts at each privilege level.
• A staging environment for the back end, so testing does not touch live customer data.
• Written authorization that names the apps, bundle identifiers and servers in scope.
• A short note on what the app protects: money, health data, identity or trade secrets. It sets the depth of the test.

Written authorization matters. Testing a server you do not own, such as a cloud service or a vendor's interface, needs that owner's permission as well. Amazon Web Services, Microsoft Azure and Google Cloud each publish their own rules for testing workloads on their platforms; check them before you start.

What a useful report contains

Expect an executive summary a board can read, then findings ranked by business impact, not by tool score. Each finding should name the MASVS control it fails, show the steps to reproduce it, describe the real-world consequence and give a specific fix. A good report also lists what passed, because that proves the control was tested. Ask for a retest of the high-severity items once your developers have fixed them.

Make it routine

Run a full test before launch and after any major change to sign-in, payments or data storage. Between those, build lighter checks into your pipeline: dependency scanning, secret scanning and automated static analysis on each build. Fix the findings that repeat in your design process, not only in the code. An app that passes a MASVS-based test is not unbreakable, but you will know what was checked, what was found and what remains.

Our team can scope a mobile test around the risks your app actually carries, and map the results to MASVS so they stand up in a customer security review.

Sources

• OWASP, Mobile Application Security Verification Standard (MASVS)
• OWASP, Mobile Application Security Testing Guide (MASTG)

This article is general information, not legal advice. Standards and vendor documentation change; confirm current requirements with your regulator, counsel and IT provider. Last reviewed November 9, 2026.

Keep reading

Next · InfrastructureOT and Warehouse Networks: Segmentation That Survives RansomwareWarehouses and plants run on operational technology that was never built to face the internet. When ransomware hits the office network, a flat design lets it reach the floor. This guide shows the zones, conduits and rules, drawn from NIST SP 800-82 Revision 3 and CISA guidance, that keep operations running.5 min read

• What a Code and Endpoint Security Review Finds in the First 24 Hours7 min
• Before Anyone Scans Your Website: Verification and Written Authorization7 min