Mobile app penetration testing

A mobile penetration test checks how the app behaves on the device and how it talks to your systems:

• Data on the device: what the app stores on the phone, and whether sensitive data is protected.
• Communication: whether traffic between the app and your servers is properly encrypted and checked.
• Sign-in and sessions: how the app authenticates users and keeps them signed in.
• Use of the platform: permissions, links between apps, and how the app uses the phone’s security features.
• The app’s code: what can be learned from the published app, and how it handles tampering, where that matters to you.
• Privacy: what personal data the app collects and sends, including through third-party components.

These follow the OWASP Mobile Application Security Verification Standard (MASVS), which lists the security controls expected in a mobile app, and its companion testing guide (MASTG), which describes how each control is tested. OWASP notes that MASVS verification cannot be completed with automated tools alone.

The mobile standard covers the app itself. The server side, usually an API, needs its own testing, and OWASP points to standards such as the Application Security Verification Standard for it. Most of your data and business rules live in that API, and anyone can talk to it directly without the app. Include it in the same engagement, or commission an API test alongside.

• Before the first public release, and before releases that change sign-in, payments or data handling.
• When a customer, partner or app review asks for evidence of independent testing.
• When the app handles personal, health or financial data.

The UK government’s voluntary code of practice for app developers asks developers to have a vulnerability disclosure process and to ship security updates, including when a third-party library they use is fixed. A penetration test is one way to find what needs fixing before someone else does.

• Platforms: iOS, Android or both, and the versions you support.
• Builds: whether testers get a pre-release build, the store version, or both.
• Accounts: a test account for each user role.
• The API: in scope or not, with its address and any documentation.
• Third-party components: payment, analytics or sign-in services you rely on but cannot authorise testing of.
• The report: findings mapped to the MASVS if your developers or customers work to it, and a retest of fixed issues.