Mobile applications handle user data, talk to platform APIs, and depend on backend services. That makes them a natural target for attackers and a genuine priority for any organisation that cares about data security. Yet mobile app penetration testing is often misunderstood, scoped too narrowly, or treated as if automated scanning will do the job. The result is gaps that leave sensitive data exposed on the device, in transit, or at the API layer.

This guide is for UK product, engineering, and security teams planning a mobile app pen testing engagement. It covers what should be in scope, how testing differs between iOS and Android, the role of OWASP standards, what to expect from providers, and how to make a good purchasing decision.

Why Mobile Apps Need Dedicated Penetration Testing

Mobile applications are not thin wrappers around web services. They store data locally, interact with platform-specific APIs, handle push notifications, use biometric authentication, and often maintain long-lived sessions. Each of these introduces risks that a standard web application penetration test or network assessment won't cover.

Vulnerabilities specific to mobile apps include:

• Insecure local storage where credentials, tokens, or personal data get written to plaintext files, shared preferences, or misconfigured databases.
• Weak transport security such as certificate pinning bypasses, missing App Transport Security (ATS) on iOS, or cleartext traffic on Android.
• Session management flaws like tokens that never expire, are predictable, or aren't invalidated on logout.
• Client-side logic exposure where business logic or secrets embedded in the binary can be reverse-engineered.
• Insecure inter-process communication (IPC) through exposed deep links, content providers, or intent handlers.

A mobile-focused pen test evaluates these risks in the context of the device, the platform, and the backend infrastructure the app depends on.

Defining the Scope

A well-scoped engagement typically covers three layers. First, the application binary itself: the iOS IPA or Android APK/AAB, its local behaviour, data storage, and platform API interactions. Second, the backend APIs the app communicates with, including authentication, authorisation, and data exchange logic. Third, session and authentication flows: login mechanisms, token handling, MFA integration, and session lifecycle.

Several scoping decisions affect cost and depth:

• Number of platforms. Testing both iOS and Android effectively doubles the platform-specific work.
• User roles. Apps with multiple permission levels (end user, admin, support agent) require authorisation testing across each role.
• API complexity. A handful of RESTful endpoints is a different proposition to a large GraphQL schema or microservices architecture. See our guide to API security testing for more on this.
• Testing approach. Black-box (no source code), grey-box (with credentials and documentation), or white-box (full source code access). White-box is more thorough but takes longer.

If you're unsure where mobile testing fits alongside broader software penetration testing, it's worth understanding the distinctions before engaging a provider.

iOS vs Android: Platform-Specific Considerations

Both platforms share common risk areas, but the technical approach differs significantly.

iOS

Testers review the app's entitlements to understand what system resources it can access, such as keychain sharing groups, push notifications, or HealthKit. Sensitive data should be stored in the iOS Keychain with appropriate protection classes; misconfigured keychain items can be extracted from jailbroken devices or unencrypted backups. Apple's App Transport Security enforces HTTPS by default, so testers check for exceptions like NSAllowsArbitraryLoads that weaken transport security. Binary analysis covers whether the app uses position-independent executables (PIE), stack canaries, and Automatic Reference Counting (ARC).

Android

Testing starts with decompilation of the APK to inspect the manifest, exported components, and hardcoded secrets. The android:debuggable flag is a common finding: if set to true in production builds, an attacker can attach a debugger and inspect runtime behaviour. Google explicitly warns against shipping debuggable builds. The Android Keystore provides hardware-backed key storage, and testers verify that cryptographic keys are stored there rather than in shared preferences or application files. Exported activities, services, broadcast receivers, and content providers without proper permission controls can be exploited by malicious apps on the same device.

Testing on both platforms requires access to physical or virtual devices. For iOS, a jailbroken device (or the ability to side-load the IPA) is often necessary for deeper inspection. For Android, a rooted device or emulator with root access is standard.

OWASP MASVS and MASTG: The Testing Baseline

The OWASP Mobile Application Security Verification Standard (MASVS) and the companion Mobile Application Security Testing Guide (MASTG) are the most widely referenced frameworks for mobile app security assessment.

MASVS defines security requirements across categories including storage, cryptography, authentication and session management, network communication, platform interaction, code quality and build settings, and resilience against reverse engineering for high-risk apps.

MASTG provides detailed test cases and techniques for verifying each MASVS requirement on both iOS and Android. It's a practical, open-source resource maintained by the OWASP community.

When evaluating providers, look for those who explicitly map findings to MASVS controls. This gives you a structured way to track remediation and benchmark your app's security over time. It also creates a common language between testers, developers, and compliance teams.

MASVS is not a compliance standard in the way ISO 27001 or Cyber Essentials is. But it's widely regarded as best practice and is increasingly referenced in procurement requirements and regulatory guidance, including the UK government's Code of Practice for App Store Operators and App Developers.

API and Backend Security

Mobile apps depend heavily on server-side logic. In many cases the app is simply a client for a set of APIs that handle authentication, data retrieval, and business operations. API security is therefore a core part of any credible mobile pen test.

Key areas of focus:

• Authorisation logic. Can a user access or modify another user's data by manipulating API requests? Insecure Direct Object Reference (IDOR) vulnerabilities remain common.
• Parameter tampering. Are server-side controls enforced, or can pricing, permissions, or workflow steps be altered by modifying requests from the client?
• Rate limiting. Are login, OTP, or password reset endpoints protected against brute-force attacks?
• Token security. Are JWTs properly signed, short-lived, and validated server-side?

A mobile pen test that ignores the API layer gives an incomplete picture. An API test conducted in isolation may miss vulnerabilities that only surface through the mobile client's specific request patterns.

Authentication and Session Risks

Authentication flows on mobile apps often differ from their web counterparts. Biometric login, device-based trust, social sign-in, and persistent sessions all introduce their own risks.

Common issues found during testing:

• Access or refresh tokens saved in plaintext on the device file system.
• Refresh tokens with no expiry or rotation, allowing indefinite access if compromised.
• Biometric authentication implemented only client-side, with no server-side verification.
• OTP codes that are too short, lack rate limiting, or are returned in the API response itself.

These tend to be among the highest-severity findings in mobile pen testing reports.

Device and Build Requirements

To get the most from an engagement, you'll need to provide the testing team with:

• Installable builds. An IPA for iOS and an APK or AAB for Android. These should be production-equivalent, not debug builds with extra logging or relaxed security settings (unless you specifically want to test the debug configuration).
• Test accounts. Credentials for each user role in scope, ideally in a staging or pre-production environment.
• API documentation. Swagger/OpenAPI specs, Postman collections, or equivalent docs to support efficient API testing.
• Device access. Confirm whether the provider uses their own devices or needs you to supply them. Most established providers maintain a lab with jailbroken iOS and rooted Android devices.

Sorting these out before the engagement starts avoids delays and lets testers spend their time testing rather than troubleshooting access.

Reporting and Retesting

A good pen testing report is more than a vulnerability list. For mobile engagements, you should expect an executive summary aimed at senior stakeholders, technical findings with severity ratings, affected components, reproduction steps, and evidence. Where applicable, findings should reference MASVS controls. Remediation guidance should be specific and practical, not generic. Exploitable vulnerabilities should include proof-of-concept demonstrations so your development team can verify each issue independently.

Retesting is typically included or offered as a follow-up at reduced cost. A retest verifies that fixes actually work. Clarify the retesting window (commonly 30 to 90 days after the initial report) and whether it covers all findings or only critical and high-severity issues.

Pricing Drivers

Mobile app pen testing costs vary widely. Based on current UK market rates, typical engagements range from roughly £5,000 to over £30,000.

The main factors: number of platforms (single vs dual), testing depth (black-box is faster and cheaper but may miss issues requiring authenticated access or code review), API scope and complexity, number of user roles and their authorisation permutations, compliance requirements that demand extra documentation or methodological rigour (PCI DSS, FCA expectations), and whether retesting is bundled or charged separately.

Be cautious of providers quoting significantly below market rates without explaining the reduced scope. Higher cost doesn't automatically mean higher quality either. Evaluate the methodology, not just the price.

How to Compare Providers

When evaluating mobile app pen testing providers in the UK, focus on a few things.

CREST accreditation is the most widely recognised quality marker for penetration testing in the UK. It's not the only indicator, but it provides baseline assurance of methodology and tester competence. Beyond accreditation, ask for anonymised examples of previous mobile app work. A provider strong in web application testing may not have the same depth on iOS and Android platform-specific issues.

Providers should be willing to explain their approach and the tools they use (Frida, objection, MobSF, Burp Suite, among others), and how they map findings to MASVS. Request a sample report before committing and evaluate it for clarity, depth, and actionable remediation advice. Good providers flag critical vulnerabilities as they find them rather than holding everything for the final report. Understand retesting terms, timeframes, and costs upfront.

A quick checklist for procurement: Does the provider hold CREST or equivalent accreditation? Can they show mobile-specific experience on both platforms? Do they map to OWASP MASVS? Is retesting included? Will they share a sample report? Do they flag critical issues during the engagement?

Getting Started

Before engaging a provider, do some groundwork. Define your objectives: are you testing for compliance, pre-release assurance, or investigating a specific concern? Agree internally on which platforms, environments, user roles, and APIs are in scope. Gather installable builds, test accounts, and API documentation in advance. Make sure your development, product, and security teams understand the timeline and their role in remediation. And budget for fixing what gets found, not just the assessment itself. Retesting costs time and developer hours too.

Mobile app penetration testing is a practical, evidence-led way to find and fix security risks before they get exploited. With clear scoping, a credible provider, and a commitment to acting on findings, it's one of the most worthwhile investments a UK organisation can make in application security.