Mobile application penetration testing
Mobile Application Penetration Testing
Test your iOS and Android apps end to end. A mobile app is more than the code on the device, so we test the app, how it stores data, and the APIs behind it. All application testing is performed by consultants who hold both GWAPT and OSWE.
What is mobile application penetration testing?
Mobile application penetration testing is an authorized, scoped test of your iOS and Android apps. A tester works with the builds your users install, such as store builds, and often the companion APIs those apps rely on. The tester checks how the app stores data, handles sessions, and talks to its backend, validates weaknesses by hand, and confirms what an attacker could actually do. You get a report of real, validated findings with practical remediation guidance, rather than raw scanner output.
If your app shares an API with a web client, see web application security testing for how that side is tested.
App and API surfaces
A mobile app is more than the code on the device. The diagram shows the installed app, transport from those builds, and the backend API. Work on the API depends on the hosts agreed in the written scope.
- 1
Installed app on the device
Agreed iOS and Android builds
- Local storage, caches, and logs
- Session and token handling on the device
- Platform configuration on the agreed packages
- 2
Transport
Traffic from the installed builds
- Transport security and certificate handling
- 3
Backend API
When those hosts are in scope
- Authentication and session handling at the agreed hosts
- Authorization between users and roles
Not sure what to include? Tell us about your app and we will help you scope it.
Mobile application penetration testing methodology, phase by phase
The phases below show how the work runs on the agreed iOS and Android builds, what you provide or receive at each step, and which OWASP mobile coverage areas the work is planned against. Backend API work depends on the hosts agreed in scope.
We use public reference frameworks such as the Penetration Testing Execution Standard (PTES) and NIST SP 800-115, the technical guide to information security testing, so your team can follow how the work was done. Client-side work is also planned against public OWASP Mobile Application Security guidance, including the Mobile Application Security Verification Standard (MASVS) and the Mobile Application Security Testing Guide (MASTG). Authorized testing only happens inside the written scope.
| Phase | What testers do | Coverage areas | What you provide or receive |
|---|---|---|---|
| Scoping and authorization | Agree the platforms (iOS, Android, or both), the builds and build variants, the device and OS versions, the roles in scope, whether backend API hosts are included, testing windows, and what is out of scope, including how root or jailbreak detection will be handled. Written authorization has to come from whoever controls each asset, including a hosted or third-party backend when its terms require it. Authorized testing only happens inside the written scope. | This phase sets which OWASP Mobile Application Security Verification Standard (MASVS) and Mobile Application Security Testing Guide (MASTG) areas can be exercised later. It does not itself test the app. | You provide written authorization, the platforms and builds in scope, the device and OS versions to use, a named contact, and any API hosts that are included. You receive a written statement of work and rules of engagement. |
| App build and reconnaissance | Install the agreed builds, such as a store build, a test build, an Android APK or AAB, an iOS IPA, or TestFlight access. Map screens, roles, platform permissions, and the APIs the app calls, and confirm the agreed build variants and OS versions can be exercised. | Planned against MASTG intelligence-gathering and app-mapping activities for the platforms and build variants that were agreed. | You provide the agreed builds and reachability for any in-scope API hosts. Mapping usually informs later phases rather than arriving as a standalone deliverable. |
| Static analysis | Inspect the app package without running it for hardcoded secrets, insecure configuration, declared permissions, and weak platform settings on the agreed iOS and Android builds. | Planned against MASVS storage, cryptography, and platform configuration areas, as they apply to the agreed builds. MASTG static tests are used as a reference, not as a claim that every test case is run. | Typically no additional handoff beyond the agreed builds. Static analysis is part of the engagement, not a separate deliverable. |
| Dynamic and runtime testing | Run the app on agreed test devices or instrumented environments. Inspect local storage, caches, and logs; watch session and token handling on the device; and check transport and certificate handling from the installed builds. | Planned against MASVS storage, authentication, network communication, and platform interaction areas that apply to the running app within the agreed scope. | You keep the agreed accounts, builds, and device or OS versions available. Dynamic testing is typically part of the engagement, not a separate handoff. |
| Backend API within scope | When API hosts are agreed, test authentication and authorization at those hosts, including between-user and role checks, using traffic from the app and deliberate request replay as agreed. An app-only scope stays on the installed packages; object-level and role checks on the backend need those hosts in the written scope. The scope-choice table later on this page shows that difference. | Planned against OWASP API Security Top 10 areas as they apply to the agreed hosts. MASVS is a mobile-app baseline and does not itself replace API testing. | You provide the in-scope API hosts and any API documentation if you have it. If this phase is not in the written scope, it is not deliberately covered. |
| Exploitation within the rules of engagement | Where agreed, a tester carefully confirms impact inside the agreed scope, accounts, builds, and window, and stops once impact is confirmed. If authorized access is obtained during an app-only test, further API work follows the agreed rules of engagement; it is not assumed from that scope. | Confirmation is for the candidate issues found in the agreed areas, not a second pass through every MASVS or MASTG test. | You provide any mid-test decisions the rules call for. If we confirm a critical-severity issue during testing, the rules of engagement set how and how quickly your named contact is told, rather than waiting for the report. |
| Reporting | Document each validated finding with steps to reproduce on the device or API, business impact, severity, and remediation guidance for the app and, when the API was in scope, the backend. Where a MASVS area applies, the finding can be described against it. | The report covers confirmed findings in the apps, builds, and APIs agreed in scope, at the same level of detail described later on this page. | You receive the written report and a readout with your team. The report shows what was found inside the agreed scope and window. |
| Retest | A retest, when included, returns to the original confirmed findings, not a second full test of every screen, build, or endpoint. When a fix lives in the app, that retest typically uses an updated build you provide. | Only the findings agreed for retest, not a new assessment of every MASVS or MASTG area. | Retest terms set in the statement of work. You provide notice that fixes are ready, and any updated build, when a retest is part of that agreement. You receive whatever that agreement sets. |
Illustrative finding, carried through the phases
Illustrative only, not a client or past engagement. Example Corp, the membership app, and api.example.com are placeholders.
Say Example Corp authorizes a test of its iOS and Android membership apps, with agreed Member accounts and the REST API at api.example.com. One finding that can be carried through these phases is a session token stored in readable local storage. It is the same illustrative finding used in the worked example later on this page.
- Scoping and authorization. Example Corp agrees the iOS and Android test builds, Member accounts, device and OS versions, and written authorization, including for api.example.com. Local storage is not named as a target. It still sits inside the agreed apps, and written authorization covers that scope.
- App build and reconnaissance. The tester installs the agreed Android test build, signs in as a member, and maps sign-in, session handling, and the API calls the app makes.
- Static analysis. The tester inspects the package for configuration and storage-related settings that could leave session material on the device.
- Dynamic and runtime testing. After sign-in on the agreed Android test build, the tester finds the API session token in a readable app preference file.
- Backend API within scope. Because api.example.com is in the written scope, the tester can confirm that the recovered token can be reused to call that API as that member.
- Exploitation within the rules of engagement. The tester confirms the impact and stops once it is confirmed, as agreed.
- Reporting. The finding is written up with a High severity, the steps to reproduce it, the business impact (someone with access to the device or a backup of it could reuse the member's session), and remediation guidance: store tokens in the platform credential store, keep them out of backups and logs, and expire them on the server when the user signs out.
- Retest. Retest terms set in the statement of work. If a retest is included, it would return to this confirmed finding after Example Corp changes how the app stores tokens, typically on an updated build.
The scope-choice table later on this page shows what app-only checks versus app plus an agreed backend API can deliberately cover, rather than repeating that comparison here. The worked example that follows it shows a full engagement, from scope to retest.
Device and backend together
Many mobile issues live in the API, not the app. Testing them together is usually the best way to see how the app and API interact.
We test on real or instrumented devices and inspect traffic between the app and its backend so gaps at the boundary are less likely to be missed.
Where the same API also serves a web client, we make sure the scope reflects that so you are not paying for overlapping work.
What we test
- How the app stores data on the device, including caches and logs.
- Authentication, session handling, and token storage.
- The APIs the app depends on, including authorization between users.
- Transport security and certificate handling.
- Client-side controls that can be bypassed or tampered with.
- Handling of sensitive data in memory and at rest.
- Platform configuration on both iOS and Android.
Our process
- 1
Scope
We agree on the platforms, builds, accounts, and APIs in scope before testing begins.
- 2
Access and setup
You provide builds and test accounts. We set up devices and confirm we can exercise the app.
- 3
Testing
We test the app and its backend manually, supported by tooling, and confirm each issue.
- 4
Reporting
You receive findings with steps to reproduce, business impact, severity, and remediation guidance.
- 5
Readout and retest
We walk through the findings with your team. Retest terms are set in the statement of work.
What a good report includes
Findings your engineers can reproduce and fix, and a summary your stakeholders can follow.
- Each finding with clear steps to reproduce on the device or API.
- Business impact described in plain language.
- Severity rated with a documented, consistent method.
- Remediation guidance for both the app and the backend.
- An executive summary that reflects the actual findings.
Scoping checklist
These questions define coverage so both sides know what is included. This is about clarity, not a checklist for choosing a vendor.
- Which platforms are in scope: iOS, Android, or both.
- Which builds and versions we should test.
- Which APIs and backend services the app uses.
- How many user roles or account types to cover.
- Any jailbreak or root detection to account for.
- What is explicitly out of scope.
- Test windows and who to contact for critical-severity findings.
Scope choice: app-only vs app plus backend API
Illustrative only, not a client or past engagement. Example Corp, the membership app, and api.example.com are placeholders.
Say Example Corp ships iOS and Android membership apps that talk to a REST API at api.example.com. Before testing, they agree in writing whether the engagement covers the installed apps alone, or the apps plus that backend API. That agreed scope decides which boundaries the test deliberately covers. It does not decide findings in advance. A penetration test is not a compliance certification. Authorized testing only happens inside the written scope.
App-only checks
The installed apps alone
Starting point
- Written authorization; agreed iOS and Android test builds; test accounts to exercise the apps; no agreed API hosts named for direct testing.
- Written authorization has to come from whoever controls each asset, including a hosted or third-party backend when its terms require it.
What you can reach
- An app-only scope stays on the installed packages.
- Object-level and role checks on the backend need those hosts in the written scope.
Deliberately covered
- Local storage, caches, and logs on the device; client-side session and token handling; transport and certificate handling from the installed builds.
- Platform configuration on the agreed iOS and Android packages, as listed in the statement of work.
App plus agreed backend API
The apps plus that backend API
Starting point
- Written authorization; the same iOS and Android test builds; test accounts for each role in scope; the API hosts in scope.
- We align on which APIs and backend services are in scope during scoping.
What you can reach
- App-only surfaces named in scope, plus authentication and authorization at those hosts, including between-user and role checks.
- Hosts, roles, tenants, or third-party services left out of the written scope stay out.
Deliberately covered
- Between-user checks, privilege-boundary checks from a member token toward staff-only actions, and authentication and session handling confirmed at the API for the roles agreed.
- API coverage is only what that scope names, not every possible endpoint or adjacent backend.
| Scope choice | What testers are given | Boundaries this choice can deliberately cover | Not deliberately covered without further agreement |
|---|---|---|---|
| App-only checks | Written authorization; Example Corp iOS and Android test builds of the membership app; Member A and Member B accounts to exercise the apps; no agreed API hosts named for direct testing | Local storage, caches, and logs on the device; client-side session and token handling; transport and certificate handling from the installed builds; platform configuration on the agreed iOS and Android packages, as listed in the statement of work | Object-level and role authorization checks on the backend that need agreed API hosts and deliberate request replay outside normal app UI flows; other server-side checks on hosts not named in scope. If authorized access is obtained during testing, further work follows the agreed rules of engagement; it is not assumed from an app-only scope |
| App plus agreed backend API | Written authorization; the same iOS and Android test builds; Member A, Member B, and one staff account; the REST API at api.example.com that both apps call | App-only surfaces named in scope, plus: between-user checks using Member A and Member B on api.example.com; privilege-boundary checks from a member token toward staff-only actions; authentication and session handling confirmed at the API for the roles agreed | Hosts, roles, tenants, or third-party services left out of the written scope stay out. API coverage is only what that scope names, not every possible endpoint or adjacent backend |
After Example Corp agrees the apps plus api.example.com in scope, the existing worked example on this page shows one way that engagement can run from scope to readout. Retest terms set in the statement of work.
What a mobile application penetration test looks like: a worked example
This is an illustrative scenario, not a real client or case study. The product, findings, and details are hypothetical and are here to show how an engagement runs from scope to retest.
Imagine a consumer membership product. Members use iOS and Android apps to book appointments and view their history. Both apps talk to a REST API at api.example.com. There are two kinds of users: a member and a staff account.
1. How scope is agreed
Before testing starts, we align with your team on the points below so both sides know what is covered.
- Platforms and builds: iOS and Android test builds of Example Corp's membership app, versions agreed before testing starts.
- API hosts: the REST API at api.example.com that both apps call.
- Roles and test accounts: two member accounts (Member A and Member B) and one staff account, so object-level and role checks can be compared.
- Authorization: written approval from whoever controls each asset in scope, including any hosted or third-party backend the app uses.
- Rules of engagement: which testing techniques are agreed, including whether jailbreak or root devices and traffic interception are in scope, how test data is created and cleaned up, and when testing pauses.
- Testing window: agreed dates and hours, plus any production constraints.
- Contacts: a named person to reach if we confirm a critical-severity issue mid-engagement.
- Out of scope: the marketing site, the third-party payment provider, other customers' real data, social engineering, and denial-of-service testing.
2. What the testers do, step by step
Within the agreed scope, testers examine OWASP Mobile Application Security Verification Standard (MASVS) areas and OWASP API Security Top 10 areas. Those references organize the work. They are not a certification, and they do not mean every item on those lists was completed.
- 1
App review and local storage
We install the agreed iOS and Android builds, map screens and roles, and examine how each app stores tokens, caches, and logs on the device. This maps to MASVS storage and platform areas within the agreed scope.
- 2
Authentication and sessions
We review sign-in, token handling, and how sessions are ended on the device and at the API. This maps to MASVS authentication areas and the API Security Top 10 authentication area.
- 3
Transport security
We inspect traffic between the apps and api.example.com and check certificate handling. This maps to MASVS network communication areas.
- 4
API authorization
We replay API calls with other members' and roles' tokens to see whether each endpoint enforces access itself. This maps to API Security Top 10 authorization areas, including object-level and function-level checks.
- 5
Sensitive data and client-side controls
We check how the app handles personal data in memory, backups, and screens, and whether client-side checks can be bypassed. This maps to MASVS privacy and resilience areas examined within the agreed scope.
3. Example findings
Illustrative only. A real report covers every confirmed finding. These four hypothetical rows show the level of detail each one carries.
| Example finding | Severity | How it is demonstrated | Business impact | Remediation guidance |
|---|---|---|---|---|
| Session token stored in readable local storage | High | On the agreed Android test build, after sign-in the tester found the API session token in a readable app preference file. The token was reused to call api.example.com as that member. | Someone with access to the device or a backup of it could reuse the member's session. | Store tokens in the platform credential store, keep them out of backups and logs, and expire them on the server when the user signs out. |
| Another member's appointment notes can be retrieved | High | Signed in as Member A, the tester changed the appointment ID on the notes endpoint at api.example.com to one that belongs to Member B. The notes were returned. | One member could read another member's appointment details. | Check ownership on the server for every object lookup, and add an automated test that fails when a cross-user request succeeds. |
| Staff-only cancel action succeeds with a member token | Medium | The cancel-for-any-member control is hidden in the member app, but sending the same request to api.example.com with a member token cancelled another member's booking. | A member could cancel other members' appointments. | Enforce role checks in the API for every endpoint, deny by default, and do not rely on the app to hide actions. |
| Device logs include the last signed-in email and a password reset link | Low | On the agreed iOS test build, the tester opened the app's debug log after a password reset and found the member's email and the reset URL. | Someone with access to device logs could recover an account reset link. | Remove sensitive values from client logs, and expire reset links after first use or a short window. |
4. The readout and the retest
After the report is delivered, we hold a readout with your engineers and stakeholders. We walk through each finding, show how it was reproduced, talk through the fix, and help your team decide what to address first based on severity and effort.
Retest terms set in the statement of work.
A penetration test is not a compliance certification. It shows what was found in the apps, builds, and APIs that were agreed in scope, and it can be one input to a broader security program.
What is included
Beyond the testing itself, you get the deliverables your team needs to prioritize and fix what we find.
- Scoped manual testing of the iOS and Android mobile clients, roles, and related APIs we agree are in scope, with tooling used to widen coverage.
- A written report with steps to reproduce, business impact, severity, and remediation guidance.
- A readout after delivery to walk through findings and answer questions.
- Retest terms set in the statement of work.
Frequently asked questions
Short answers to common questions about scoping a mobile application penetration test.
Do you test iOS, Android, or both?
Either or both. We agree on the platforms, builds, and versions in scope before testing begins. Many teams test both because the two apps often share the same backend but handle storage and platform settings differently.
Is the backend API included?
It can be, and it often should be, because many mobile issues live in the API rather than the app. We align on which APIs and backend services are in scope during scoping. If the same API also serves a web client, we reflect that in scope so the work does not overlap with a web application test.
What do you need from us?
The app builds to test, such as store builds or test builds, test accounts for each role in scope, the API hosts in scope, written authorization, and a named contact. Authorization has to come from whoever controls each asset, including any hosted or third-party backend services the app uses.
Will testing affect our users or production data?
Testing is planned to keep that risk low. We agree on test accounts, environments, and testing windows before testing begins. If we confirm a critical-severity issue during testing, the rules of engagement set how and how quickly your named contact is told, rather than waiting for the report.
Is an app-only mobile test enough if we already scan the builds?
An app-only mobile test and a build scan can both be useful on the packages named in scope. Object-level and role authorization on the backend API, and other server-side checks that need agreed API hosts and deliberate request replay, are not deliberately covered without that API in the written scope. If authorized access is obtained during testing, further work follows the agreed rules of engagement. When the app depends on an API for bookings, accounts, or other sensitive actions, ask for those API hosts in the statement of work. A mobile application penetration test is not a compliance certification. It shows what was found inside the agreed scope and window. Retest terms set in the statement of work.
How long does a mobile application penetration test take?
It depends on scope, such as the number of platforms, user roles, and APIs in scope. We agree on a timeline during scoping.
Is a mobile application penetration test a compliance certification?
No. A mobile application penetration test is not a compliance certification. It shows what was found in the apps, builds, and APIs that were agreed in scope, and it can be one input to a broader security program.
What methodology does a mobile application penetration test follow?
A mobile application penetration test typically follows scoping and authorization, app build and reconnaissance, static analysis, dynamic and runtime testing, backend API testing when those hosts are in scope, exploitation within the rules of engagement, reporting, and a retest. Client-side work is planned against OWASP MASVS and MASTG areas as they apply to the agreed platforms and builds. Authorized testing only happens inside the written scope. A mobile application penetration test is not a compliance certification. It shows what was found inside the agreed scope and window. Retest terms set in the statement of work.
Scope a mobile application test
Tell us about your app and we will follow up with next steps.