Mobile App Penetration Testing Guide (iOS & Android)

A mobile app is a strange thing to secure. You ship it to people you’ve never met, onto devices you don’t manage, and they can unpack it, read it and watch every request it makes. Anything the app knows, a determined user can find out. Any rule the app enforces on its own, they can switch off.

That is the lens a mobile penetration test uses. This guide explains what a mobile pentest covers on iOS and Android, how the OWASP Mobile Application Security Verification Standard (MASVS) shapes it, what testers need from you, and the issues that come up most often.

Why mobile apps need their own testing

Your web application and your mobile app often share a backend. So why not test the API once and move on?

Because the app itself is part of the attack surface:

• It stores things. Tokens, cached responses, logs and screenshots end up on the device.
• It talks to the operating system. Deep links, intents, extensions and WebViews all open doors into the app.
• It can be taken apart. Anyone can download it, decompile it and look for hardcoded secrets, hidden endpoints or debug features.
• It makes trust decisions. Some apps decide locally what a user may see or do. Those decisions can be bypassed.

A web test won’t cover any of this. Equally, a mobile test that only looks at the device misses the backend, which is where the most damaging issues usually live. A good mobile engagement does both.

OWASP MASVS: the framework behind the test

The OWASP MASVS is the industry’s standard for mobile app security requirements. Its companion, the Mobile Application Security Testing Guide (MASTG), describes how to test each one. Version 2 of MASVS organises requirements into eight control groups.

Control group	What it covers	Typical questions a tester asks
MASVS-STORAGE	Sensitive data stored on the device	What ends up in files, databases, logs, backups and caches?
MASVS-CRYPTO	Use of cryptography	Are algorithms current? Are keys hardcoded or managed properly?
MASVS-AUTH	Authentication and authorization	Are sessions and tokens handled safely? Does the backend enforce access?
MASVS-NETWORK	Network communication	Is all traffic encrypted? Is certificate validation done correctly?
MASVS-PLATFORM	Interaction with the operating system	Are deep links, IPC, WebViews and the clipboard used safely?
MASVS-CODE	Code quality and dependencies	Are inputs validated? Are third-party libraries up to date?
MASVS-RESILIENCE	Resistance to reverse engineering and tampering	How hard is it to modify, hook or repackage the app?
MASVS-PRIVACY	User privacy	Does the app collect and share only what it needs, transparently?

Not every group matters equally for every app. A banking app needs strong resilience controls. A simple internal tool may not. Part of scoping is agreeing which areas carry the most risk for your product.

What a mobile pentest covers on each platform

iOS and Android share the same goals but very different mechanics. Here is where testers focus on each.

iOS

• Local data storage: files, Core Data and SQLite databases, NSUserDefaults, caches, screenshots taken when the app goes to the background, and what ends up in device backups.
• Keychain: what is stored there and with which access-control attributes, for example whether items are available when the device is locked.
• Network security: App Transport Security exceptions, certificate validation and certificate pinning.
• URL schemes and universal links: what they can trigger inside the app, and whether their input is validated.
• Extensions and shared containers: what app extensions and shared app groups can read.
• WebViews: how WKWebView is configured and what JavaScript bridges expose.
• Binary protections: how easily the app can be modified or instrumented at runtime, and how jailbreak detection behaves.

Android

• Local data storage: shared preferences, SQLite databases, external storage, logs and backups.
• Keystore: how keys are generated, where they live and whether hardware-backed storage is used.
• Network security: the network security configuration, cleartext traffic and certificate pinning.
• Exported components: activities, services, broadcast receivers and content providers that other apps can reach.
• Intents and deep links: what other apps or links can make yours do.
• WebViews: JavaScript settings, file access and exposed JavaScript interfaces.
• Reverse engineering and tampering: obfuscation, integrity checks, repackaging and root detection.

The backend API

Both platforms talk to an API, and that is where testers spend a large share of their time. The same checks as any API penetration test apply: can a user reach another user’s data, call admin functions, replay or forge tokens, or abuse business flows?

Testing the API through the mobile app has one advantage. Testers see exactly which endpoints the app uses, including ones that were never documented.

Common mobile findings

Every app is different, but some issues come up again and again.

Secrets in the app package

API keys, third-party service credentials and internal URLs hardcoded in the app. Anything in the package should be considered public. If a key grants access to something valuable, it shouldn’t be in the app at all.

Sensitive data left on the device

Access tokens in plain files, personal data in caches, full API responses in logs, or sensitive screens captured in the app-switcher snapshot. Each is readable by anyone with access to the device or its backups.

Trusting the client

Features unlocked by a local flag, prices or limits checked only in the app, or “premium” content hidden by the interface but served by the API to anyone who asks. If the server doesn’t enforce a rule, the rule doesn’t exist.

Weak transport security

Certificate validation disabled for testing and never re-enabled, cleartext traffic allowed for some domains, or pinning implemented in a way that’s trivially bypassed. These open the door to interception on hostile networks.

Exposed platform entry points

An exported Android component that performs an action without checking who called it, or a deep link that loads an arbitrary URL into a WebView with a powerful JavaScript bridge. These let other apps or malicious links drive your app.

Broken authorization in the backend

Changing an ID in a request returns another user’s data. This is often the most damaging class of issue in a mobile engagement, and it’s a backend problem, not a mobile one.

What testers need from you

Preparation decides how much of the test is spent testing. For a mobile engagement, have these ready before kickoff:

• Test builds for each platform. An IPA via TestFlight or an ad hoc build for iOS, and an APK or AAB for Android. Debug or test builds pointed at a staging backend work best.
• Test accounts for every user role, ideally in two separate customer accounts if your product is multi-tenant.
• Backend details: the environment the builds talk to and any API documentation or collections.
• Notes on hard-to-reach features: anything that needs special hardware, data or approval to trigger, such as payments or identity verification.
• A technical contact for each platform who can answer questions and issue new builds quickly.
• An agreed testing window.

Choosing a release-protection approach

Production apps often include protections such as obfuscation, jailbreak or root detection and certificate pinning. They raise the bar for casual attackers, and MASVS-RESILIENCE treats them as a legitimate layer of defence.

During a test, though, these protections can eat time that would be better spent finding real weaknesses. There are two common approaches:

Approach	What it means	When it fits
Test build without protections	Testers get a build with pinning and detection switched off	Most engagements. Maximises time on real vulnerabilities.
Production-equivalent build	Testers work against the real protections	When you specifically want to know how resilient the app is to tampering.

Many engagements use both: a test build for the bulk of the work, plus a focused look at the production protections.

How to read and act on the results

A mobile report should separate findings in the app from findings in the backend, because different teams usually fix them. For each finding, look for the platform affected, the evidence, the steps to reproduce and a recommended fix.

When prioritising, start with anything that exposes other users’ data or lets someone act as another user. These usually sit in the API and can often be fixed without shipping a new app version, which matters because users update apps slowly.

Fixes in the app itself need a release, and old versions stay in the wild. Where a client-side issue is serious, consider whether the backend can mitigate it too, for example by expiring tokens or rejecting requests from outdated app versions.

After you fix the findings, a retest confirms what has been resolved. That retest status is what auditors and enterprise customers look for. Our sample report shows how findings and retest status are presented.

Bringing it together

A mobile app pentest checks the app on the device, its interaction with the operating system and the backend it depends on. MASVS gives the work a clear structure, and preparation decides how far the testing gets.

If you’re planning a test, our mobile app penetration testing page explains how we approach iOS and Android together, and our methodology explains how we rate and report findings.