Article contents
- In short
- What is checked: table
- Data on the phone
- Connection to the server and the API
- Login, sessions and access rights
- Payments and in-app purchases
- Secrets in the code and protection against reverse engineering
- The app's server (backend)
- iOS and Android: what is different
- What the client provides
- What you get as a result
- Checklist before a mobile app pentest
- FAQ
- References
A mobile app penetration test checks six things: what data the app leaves on the phone, how it talks to the server and its API, how login and sessions work, whether payment can be bypassed, whether passwords and keys are built into the code and whether the app's own server is protected. For iOS and Android the basis is OWASP MASVS (a list of security requirements for mobile apps) and the OWASP MASTG guide (how exactly to test them), while the server and API are tested with the OWASP method for web applications. [1] [4]
Mobile app penetration testing means a manual check of the app and its server in which a specialist acts like an attacker: takes the build apart, intercepts the traffic and tries to reach other people's data, money or features. Below is a table with example risks, an explanation of each part, what to give the tester and what you get back. The general format of the work is described on the penetration testing page.
In short
- As of October 2026 the current versions are OWASP MASVS v2.1.0 (January 2024) and MASTG v2.0.0 (June 2026). Ask the provider which versions they work with. [2] [3]
- MASVS splits the check into eight groups: data storage, cryptography, login and access rights, network, interaction with the phone, code quality, resistance to reverse engineering and privacy. [1]
- MASVS itself does not cover the server. The most serious problems often live in the API, so include it in the scope. [4]
- From the client you need builds for iOS and Android, test accounts for every role, an API description and a developer contact.
- The result: a report with reproduced findings, business impact and the order of fixes, and a retest after the fixes if it was agreed.
What is checked: table
| What is checked | Example risk | Why it matters to the business |
|---|---|---|
| Data on the phone | The login token and card number sit in a file without encryption | A lost or infected phone must not become a leak of customer data |
| Connection to the server | The app trusts any certificate, so traffic on public Wi-Fi can be tampered with | Nobody in the middle reads or changes customer requests |
| Server API | Changing a number in a request shows another user's profile | One customer cannot see another's data, and a leak does not make the news |
| Login and sessions | An old token still works after logout, the SMS code can be guessed | Accounts cannot be taken over, a stolen session expires quickly |
| Payments and purchases | The app decides on its own that a purchase succeeded, the server does not check | Paid access is not handed out for free, no losses to fraud |
| Secrets in the code | The build contains a key to cloud storage or a payment service | A key cannot be pulled out of the app store and used against you |
| Interaction with the phone | Another app opens an internal screen through a link | Other apps on the phone do not get extra access |
| Resistance to reverse engineering | A limit or access check is easy to switch off in a modified build | Important rules are enforced by the server, not the user's phone |
Data on the phone
The tester installs the app, goes through the main scenarios and looks at what is left on the device: files, the local database, logs, cache, backups, screenshots in the app switcher. A typical finding: the session token (a digital pass issued after login) or personal data stored in plain form, although iOS and Android both have protected stores for keys, Keychain and Keystore.
The tester also checks what ends up in logs and in phone backups. MASVS puts data storage into its own group of requirements. [1]
Connection to the server and the API
An API is the way the app talks to the server: each button in the app usually becomes a request. The tester intercepts these requests and checks two things. First, whether the connection is encrypted and whether the app checks the server's certificate, so nobody in the middle can swap the response. Second, whether the server checks every request instead of trusting the app.
The most common serious problem looks simple: a request contains an order or profile number, and if you change it, the server returns someone else's data. The mobile interface never shows this, but an attacker works with the requests directly, without the app. More on API testing in how website and API security is tested.
Login, sessions and access rights
Here the tester follows the whole user journey: sign up, login, password reset, fingerprint or face login, logout. Typical questions: can the SMS code be guessed, does the session end after logout and after a password change, can biometric login be bypassed just by changing the app's response.
MASVS states plainly that access decisions must be made by the server, and the app only has to use the login protocols correctly. Sensitive actions, such as a money transfer or a phone number change, need extra confirmation. [8] Roles are checked separately: can a regular user call a manager or admin function.
Payments and in-app purchases
If the app has payments, subscriptions or bonuses, the tester looks for a way to get paid features without paying: change the amount in a request, repeat a bonus request, fake a "paid" response. For Android, Google directly advises moving sensitive logic to your own server and verifying every purchase there before granting access. [6]
The payment provider and the app stores belong to other companies. They are not tested, only your integration with them.
Secrets in the code and protection against reverse engineering
Any build from the App Store or Google Play can be downloaded and taken apart. So the tester looks for built-in passwords, API keys, internal service addresses and test accounts. OWASP describes secrets hardcoded in the app package as a separate weakness. [5] The rule is simple: everything inside the app will sooner or later be seen by an outsider.
Resistance to reverse engineering (protection against changing and copying the app) is not needed by everyone. For banking apps, games with paid items or apps with valuable content it is checked more deeply: does the app run on a phone with the system protection broken (rooted or jailbroken), does it notice changes to its own code. But this protection only makes an attack harder, and important rules still have to be enforced by the server.
The app's server (backend)
The backend means the servers and databases the app works with. MASVS and MASTG do not cover it and advise testing it separately against OWASP standards for web applications, including the WSTG guide. [4] [7] In practice a mobile pentest without the API gives an incomplete picture: the app can be built carefully while the server hands out other people's data to anyone who knows the request address.
So the scope should say it directly: iOS app, Android app, API, admin panel if there is one. If something stays out of scope, the report should show it.
iOS and Android: what is different
The MASVS requirements are the same for both platforms, while the test methods in MASTG are written separately for each. [3] What differs is the protected storage, the permission rules, the way other apps can open your screens and the analysis tools. That is why the two versions of one app are tested separately: a bug often exists on only one platform, because different people write them.
What the client provides
MASVS recommends an "open book" format: the tester has access to the developers, documentation, source code and at least one account for each role. [4] The minimum worth preparing:
- builds for iOS (through TestFlight or a file for a test device) and Android (an APK or AAB file), ideally without extra anti reverse engineering protection for the main part of the test;
- two test accounts per role, to check whether one user can reach another user's data;
- an API description or a collection of requests, and the address of the test server;
- test cards or the payment provider's sandbox, if there are payments;
- a developer contact for quick questions and written permission with the scope.
The full list of steps is in how to prepare for a pentest.
What you get as a result
- A short summary for management: what was found, what it means for the business, what to fix first.
- Findings with steps to reproduce, evidence and a risk rating, separately for iOS, Android and the API.
- Specific recommendations for developers, not general advice.
- A list of what was tested and what stayed out of scope.
- A retest after the fixes, if it is agreed in the contract, with written confirmation of what is closed.
The timeline depends on the number of platforms, roles and features, so it is fixed before the start. If the scope is not clear yet, start with a description of the app and a penetration test of the most important scenarios: login, customer data and payments.
Checklist before a mobile app pentest
Download the preparation checklist (PDF)PDF · A4
FAQ
What is checked in a mobile app penetration test?
The data the app stores on the phone, the connection to the server and the API, login and sessions, payments, secrets built into the code, interaction with other apps and, if needed, resistance to reverse engineering. The basis is OWASP MASVS and MASTG, and the server is tested with the OWASP method for web applications.
Do iOS and Android need to be tested separately?
Yes. The requirements are the same, but the platforms store data and give access to other apps differently, and the code is often written by different teams. A bug in one version does not mean it exists in the other, and the other way round.
Is the API part of a mobile app pentest?
It should be, but write it down explicitly. MASVS covers only the app itself, while the most serious problems, such as access to other people's data, usually live on the server.
Do we need to share the source code?
Not necessarily, a test can be done with builds only. But with code and documentation the check goes deeper in the same time, and MASVS recommends exactly this open format.
How often should a mobile app be pentested?
Usually once a year and after big changes: new payments, a new login method, a move to another server. Between pentests, automated checks in the app build process help.
References
- OWASP MASVS: The Mobile Application Security Verification Standard mas.owasp.org
- OWASP MASVS v2.1.0 release (January 2024) github.com
- OWASP MASTG v2.0.0 release (June 2026) github.com
- OWASP MASVS: Assessment and Certification mas.owasp.org
- OWASP MASWE-0004: Sensitive Data Hardcoded in the App Package mas.owasp.org
- Android Developers: Play Billing, Fight fraud and abuse developer.android.com
- OWASP Web Security Testing Guide wstg.owasp.org
- OWASP MASVS-AUTH: Authentication and Authorization mas.owasp.org
