Skip to content

Mobile App Penetration Testing: What Gets Tested and How It Differs from Web Apps

What a mobile app penetration test covers, from device storage and APIs to authentication and the OWASP Mobile Top 10, and how it differs from web apps.
Mobile App Penetration Testing_ What Gets Tested and How It Differs from Web Apps

Mobile apps have become the front door for a huge number of businesses. Customers bank, shop, book appointments and manage their accounts through them, and staff increasingly use them to reach internal systems. Yet security testing for mobile apps is often far less thorough than it is for websites, partly because many organisations assume that a web application test covers them too.

It doesn’t. A mobile app runs on a device you don’t control, stores data locally, talks to back-end APIs in ways a browser never would, and can be downloaded and taken apart by anyone with a copy. This guide explains what mobile application security testing actually covers, how it differs from testing a web application, and how the OWASP Mobile Top 10 fits in.

What is Mobile App Penetration Testing?

Mobile app penetration testing, sometimes simply called mobile penetration testing, is a security assessment in which testers attack an iOS or Android app, and the services behind it, in the same way a real attacker would. The aim is to find weaknesses in how the app stores data, handles authentication, communicates with its servers and protects itself from tampering, and then to show how those weaknesses could be exploited.

A good mobile pen test looks at the whole system, not just the app on the phone. In most cases, the most serious vulnerabilities sit in the APIs the app relies on, so a test that only examines the app itself misses a large part of the picture. Fortifi’s mobile app penetration testing service covers both.

How Mobile App Testing Differs from Web App Testing

Mobile and web applications often share the same back end, so there’s a natural overlap between the two kinds of test. But the differences are significant, and they’re the reason a mobile app needs its own assessment.

Web application Mobile application
Where the code runs Mostly on your servers, with the browser displaying the results Much of the logic runs on the user’s device, which you don’t control
Access to the code Users only see what the server sends them Anyone can download the app and reverse engineer it
Local data Limited to cookies and browser storage Files, databases, caches, logs and keychains on the device
Communication Standard browser traffic Direct API calls, which may be less protected or expose extra functions
Platform features Few Permissions, deep links, biometrics, push notifications and interaction with other apps
Updates Fixes apply to every user immediately Users may stay on old, vulnerable versions for months

Interestingly, the point about updates is often overlooked. When a vulnerability is fixed on a website, every user gets the fix straight away. When it’s fixed in a mobile app, some users will keep running the old version until they update, which is one more reason to find problems before release instead of after.

If you’d like to understand the web side in more detail, our guide to web application penetration testing covers what that involves.

What Gets Tested in a Mobile App Penetration Test

Every app is different, but these are the main areas a thorough test will cover.

Data stored on the device

Apps often store more on the device than their developers realise, including authentication tokens, personal information, cached API responses and log files. Testers check what’s stored, where it’s stored and how well it’s protected, including whether sensitive data is kept in the platform’s secure storage (the iOS Keychain or Android Keystore) or left in plain text. They’ll also look at what ends up in device backups, screenshots and system logs, since a lost or compromised phone can expose all of it.

API calls and the back end

This is usually where the most serious problems are found. Testers intercept and manipulate the traffic between the app and its servers, looking for issues such as one user being able to access another user’s data by changing an ID, functions that the app hides but the API still allows, and missing checks that the developers assumed the app would enforce. Because the same APIs often serve a web application too, findings here can affect more than just the mobile app.

Authentication and session management

Testers check how users log in and stay logged in, including password handling, multi-factor authentication, biometric login, token expiry and logout. A common issue is authentication that’s enforced only by the app itself, such as a biometric check or PIN screen that can be bypassed on a compromised device because the server never verifies it.

Network communication

Testers confirm that all traffic is encrypted properly and that the app can’t easily be tricked into talking to an attacker’s server. Where the risk justifies it, they also check that certificate pinning is implemented correctly, which makes it much harder for an attacker to intercept the app’s traffic.

The app binary and its code

Since anyone can download an app, testers analyse the app itself, looking for hardcoded secrets such as API keys and credentials, debugging features left in production builds, and weaknesses in obfuscation, jailbreak or root detection, and tamper protection. These protections can’t make an app impossible to reverse engineer, but they raise the bar significantly.

Third-party libraries and SDKs

Most apps include third-party code for analytics, advertising, payments or crash reporting. Each of those components can introduce vulnerabilities or collect data in ways you didn’t intend, which makes them part of your supply chain risk.

Interaction with the device and other apps

Mobile platforms let apps share data and respond to links from elsewhere, through features such as deep links, Android intents and custom URL schemes. Testers check that another app or a malicious link can’t use these features to trigger actions, steal data or bypass security checks. They’ll also review the permissions the app requests, to make sure it isn’t asking for more access than it needs.

The OWASP Mobile Top 10

The OWASP Mobile Top 10 is a widely used list of the most critical security risks for mobile applications. Its 2024 edition, which Cobalt describes as the first major update since 2016, gives a useful framework for understanding what a mobile pen test is looking for:

Risk What it means in practice
M1: Improper credential usage Hardcoded credentials, or credentials stored or transmitted insecurely
M2: Inadequate supply chain security Vulnerable or malicious third-party libraries, SDKs or build processes
M3: Insecure authentication/authorisation Weak login controls, or permissions checked on the device instead of the server
M4: Insufficient input/output validation Data that isn’t properly checked, opening the door to injection attacks
M5: Insecure communication Weak or missing encryption of data in transit
M6: Inadequate privacy controls Personal data collected, stored or shared without adequate protection
M7: Insufficient binary protections Apps that are easy to reverse engineer or tamper with
M8: Security misconfiguration Insecure default settings, excessive permissions or debugging left enabled
M9: Insecure data storage Sensitive data stored on the device without proper protection
M10: Insufficient cryptography Weak algorithms, poor key management or homemade encryption

If you’re familiar with the web version, our guide to the OWASP Top 10 explains how that list works. For more detailed testing, OWASP’s Mobile Application Security project also publishes the MASVS, which is a standard for mobile app security requirements, and the MASTG, which is a guide to testing against it. Crucially, the Top 10 is a starting point, not a complete checklist. A good tester will use it alongside these resources and their own experience of how apps actually fail.

How a Mobile App Penetration Test Works

Scoping

The tester needs to know which platforms are in scope, whether that’s iOS, Android or both, which versions of the app, which APIs it uses and which user roles exist. You’ll usually need to provide test accounts and access to the app outside the public app store, such as a test build. Testing against a non-production environment is often the safest option for apps that handle payments or sensitive data.

Testing

Testing typically combines static analysis, where the tester examines the app’s code and configuration without running it, with dynamic analysis, where they run the app on test devices and intercept and manipulate its behaviour. The back-end APIs are tested alongside the app. Much of this work is manual, because the most serious issues, such as access control flaws, can’t be found reliably by automated tools, as we explain in our guide to automated vs manual penetration testing.

Reporting and retesting

The report should explain each finding, how it could be exploited and how to fix it, with guidance your developers can act on. Once fixes are in place, retesting after fixing vulnerabilities confirms they work before the next release goes out to users.

Do You Need to Test Both iOS and Android?

Usually, yes. Even when both versions of an app share the same design and back end, they’re built with different code and rely on different platform security features, so a vulnerability in one may not exist in the other, and vice versa. Apps built with cross-platform frameworks such as React Native or Flutter share more code, which can reduce the work involved, but each platform still has its own storage, permissions and security behaviour that needs checking. The back-end APIs only need testing once, which helps keep the cost of covering both platforms down.

When Should You Test a Mobile App?

Notably, the best time to test is before a vulnerability reaches users, given how slowly some users update. The most common triggers for mobile application security testing are:

  • Before launch, so issues are fixed before the app is in the hands of the public.
  • After major releases, especially those that add payments, new login methods or access to sensitive data. If your app now includes AI features, such as an in-app assistant, our LLM testing covers the risks those introduce.
  • For compliance and customer requirements, such as apps that handle card payments, where PCI DSS penetration testing applies, or SaaS products going through SOC 2, which we cover in “Does SOC 2 require penetration testing?“
  • At least once a year, for apps that change regularly or hold sensitive data.

If you’re budgeting for a test, our guide to how much a penetration test costs explains what drives the price.

Mobile App Penetration Testing with Fortifi

Fortifi is a CREST-accredited penetration testing company, and we test iOS and Android apps together with the APIs and cloud services behind them. If your app shares its back end with a website, we can combine the work with web app penetration testing so nothing falls between the two.

Because we don’t do sales calls, you’ll speak directly to a cyber security expert who can help you scope a test around your app, your platforms and your release schedule. Book a call with our team today.

Mobile App Security Testing FAQs

What is the difference between mobile and web app penetration testing?

Web app testing focuses on code running on your servers and accessed through a browser. Mobile app testing also covers code running on the user’s device, including how the app stores data locally, how it can be reverse engineered and how it interacts with the device and other apps. Both usually include testing the back-end APIs.

Does a mobile pen test include the API?

It should. Most of the serious vulnerabilities in mobile apps are found in the back-end APIs, so testing the app without its APIs leaves a significant gap. Make sure the API is clearly included in the scope when you get a quote.

How long does mobile app penetration testing take?

It depends on the size and complexity of the app, the number of user roles, the APIs involved and whether one or both platforms are in scope. A simple app might take a few days, while a complex app with many features and integrations can take considerably longer.

Can automated tools test a mobile app?

Automated tools can scan an app for known issues, such as insecure configuration or outdated libraries, and they’re useful between tests. But they can’t reliably find problems such as broken access controls or business logic flaws in the API, which is why mobile pen testing relies heavily on manual work.


Recent posts

How Penetration Testing Supports ISO 27001 Compliance

Read more

How Much Does a Penetration Test Cost in the UK? What Drives the Price

Read more

What Auditors Want to See in a Penetration Test Report

Read more

Penetration Testing for Cyber Insurance: What Insurers Are Starting to Ask For

Read more