Mobile app penetration testing for Android and iOS

Mobile app penetration testing evaluates much more than an APK or IPA file. A useful assessment covers the Android or iOS client, local data, platform security controls, network communication, reverse-engineering resistance and the backend APIs that enforce identity and business rules.

Many serious mobile findings are actually distributed-system failures. A token is stored insecurely on the device, an API accepts another customer’s object identifier, and a notification exposes sensitive content on a locked screen. Testing only one layer misses the chain.

What is a mobile application pentest?

A mobile pentest is an authorised security assessment of the application and its supporting services from an attacker’s perspective. The tester analyses the package statically, runs it on controlled devices, intercepts traffic and attempts to abuse server-side functions with different roles and accounts.

The scope should identify:

Android and iOS applications and exact build versions;
distribution channel and signing model;
production or staging backend environments;
API endpoints, authentication and third-party services;
user roles, organisations and test accounts;
sensitive business flows such as payments or identity checks;
permitted actions, test data and operational restrictions.

A mobile pentest is not a generic scanner report. Automated tools can find exported components, embedded secrets and known libraries, but they do not understand whether a support user can approve their own transaction or whether one tenant can retrieve another tenant’s attachment.

MASVS and MASTG as the technical baseline

The OWASP Mobile Application Security Verification Standard defines security control groups for mobile applications. The OWASP Mobile Application Security Testing Guide provides testing techniques and cases.

The principal MASVS areas include storage, cryptography, authentication, network communication, platform interaction, code quality, resilience and privacy. They create a common language for developers and testers, but the engagement must still add business-specific scenarios.

An important current detail is that MASVS version 2 no longer uses the old L1, L2 and R verification levels inside the standard. Testing depth is expressed through separate testing profiles. A proposal that automatically promises “MASVS L2” without clarifying the version and profile may be referring to an obsolete structure. Use the official MAS checklist and record the exact standard version.

Android penetration testing coverage

Package and manifest analysis

The tester reviews the manifest, permissions, exported activities, services, receivers, content providers, intent filters, deep links, backup configuration and network-security settings. Exported components can become unauthorised entry points if they rely on the UI for access control.

Custom URL schemes and app links require special attention. Malicious applications or websites may intercept a scheme, inject parameters or trigger sensitive flows without the intended context.

Local storage

Sensitive information may appear in SharedPreferences, SQLite databases, files, caches, WebView storage, logs, screenshots and backups. Encryption helps only when key management and access boundaries are correct. A key stored beside the ciphertext provides little protection against device compromise or package extraction.

The assessment should verify what remains after logout, account removal and application uninstall. Test notifications and recent-app previews because they can expose information without unlocking the application.

Runtime behaviour

Dynamic analysis observes method calls, filesystem activity, cryptographic use, IPC and network traffic. Root detection and anti-tampering controls can increase attacker cost, but they must not replace server-side authorisation. The tester should document whether controls are effective and whether bypassing them creates a real business impact.

WebView and native integration

WebViews may introduce JavaScript bridges, unsafe navigation, file access and mixed-content problems. Only trusted origins should access privileged native interfaces. URL validation must handle redirects, encoding and lookalike domains.

iOS penetration testing coverage

Entitlements and platform configuration

The tester reviews entitlements, URL schemes, Universal Links, App Transport Security exceptions, keychain-access groups, application groups and background modes. Excessive entitlements widen the attack surface and can expose data to related applications.

Keychain and local data

The iOS Keychain is appropriate for many credentials, but the accessibility class must match the threat model. Items that remain accessible while the device is locked or migrate to backups may violate the intended protection. Files, Core Data, caches, pasteboard content and logs require separate review.

Inter-application communication

Universal Links and custom schemes should bind navigation to expected domains and validate all parameters. Extensions and shared app groups need explicit data boundaries. The application must not assume that a request is trusted merely because it arrived through an OS feature.

Jailbreak and instrumentation resistance

Resilience controls are relevant for applications handling high-value transactions, secrets or intellectual property. Testers assess whether instrumentation, repackaging or debugging can bypass a business control. The objective is not to claim an unbreakable client; any decision that matters must still be enforced on the server.

Backend API testing is mandatory

The mobile client is controlled by the user and can be modified. An attacker can replay requests, remove UI restrictions, alter identifiers and call undocumented endpoints. Therefore the backend must treat every client request as untrusted.

The assessment should cover:

object-level and function-level authorisation;
tenant isolation and ownership checks;
token issuance, rotation, audience and revocation;
device registration and account recovery;
rate limits and anti-automation controls;
mass assignment and hidden fields;
file upload and download authorisation;
push-notification registration;
business-logic abuse and transaction limits;
GraphQL introspection, query depth and batching where applicable.

Use our API penetration testing checklist for deeper coverage. A certificate-pinning bypass is not the final impact; it is often a step that enables observation and manipulation of an API flow.

Authentication, biometrics and session security

Biometric authentication typically releases a locally stored credential or authorises a sensitive action. The server does not receive proof that a fingerprint itself was checked unless the design uses an appropriate cryptographic challenge and attestation model.

Test whether biometric fallback can be abused, whether the app accepts a simple local boolean, and whether changing enrolled biometrics invalidates protected material when required. For high-risk actions, server-side re-authentication or transaction signing may be necessary.

Session tests should cover refresh tokens, concurrent devices, logout, password changes, account disabling and device loss. “Logout” must revoke or isolate relevant credentials rather than only deleting a UI state.

Transport security and certificate pinning

All sensitive communication should use correctly validated TLS. The tester checks certificate validation, hostname verification, cleartext exceptions, obsolete protocols and whether data leaks through analytics or third-party SDKs.

Certificate pinning can make interception harder on an uncompromised device, but it is a resilience layer, not an authorisation control. A determined attacker controlling the runtime can often bypass it. Server-side access control, minimal token scope and anomaly detection remain necessary.

Embedded secrets and third-party SDKs

Mobile packages are distributed to users, so any embedded value can be extracted. Public identifiers and restricted client keys may be acceptable; administrative API keys, private signing material and universal backend secrets are not.

Review analytics, crash reporting, advertising, customer-support and identity SDKs. They may collect personal data, include vulnerable dependencies or send information to additional jurisdictions. Maintain an inventory and software bill of materials for the released package, not only the source repository.

How to prepare for a mobile pentest

Provide:

the exact APK, AAB-derived APK or IPA build;
source maps or symbols when available;
API documentation and architecture diagram;
accounts for each role and at least two tenants;
safe payment, identity and notification test data;
a contact who can inspect backend logs;
build and signing information relevant to the test;
known limitations and prohibited production actions.

Staging should match production security configuration. If pinning, identity, rate limiting or third-party integrations are disabled, document the difference and verify critical controls separately.

What the report should contain

A good report identifies the platform, build hash, environment, device assumptions and access model. Each finding should include evidence, impact, affected versions, reproduction steps and a fix at the correct layer.

For example, do not remediate a server-side IDOR by hiding an identifier in the mobile UI. The API must verify ownership. Do not remediate an embedded secret only by obfuscating the string. Replace it with a server-mediated flow or a restricted public credential.

The report should map relevant findings to MASVS controls and separate client, API and infrastructure issues. Retesting must use the fixed build and confirm that server changes are deployed to the assessed environment.

Mobile pentest checklist

Define Android, iOS, API and third-party scope.
Record exact build versions and hashes.
Review manifest, entitlements, permissions and exported interfaces.
Test local files, databases, keychain, logs, backups and screenshots.
Inspect TLS, pinning, analytics and external destinations.
Validate authentication, biometrics, sessions and device change.
Test every role and tenant directly against the API.
Review deep links, WebViews and inter-application communication.
Extract and classify embedded keys and components.
Evaluate reverse-engineering resistance according to risk.
Test high-impact business flows and anti-automation controls.
Retest fixes on both client and backend.

A mobile app is a client in an untrusted environment, not a security boundary. The strongest assessment follows data and authority from the device to the backend and back. To scope an Android or iOS engagement, contact Breachroad with your builds, API inventory and user roles.