Mobile Application Penetration Testing: iOS and Android Attack Surface

When an organisation commissions a web application penetration test, it is natural to assume that the mobile version of the same application is also covered. It is not. A web application test examines the server-side logic and the HTTP traffic between a browser and the server. The mobile application introduces a separate attack surface: the binary that runs on the device, the way the application stores data locally, the certificates it trusts, and the controls it implements in client-side code. These are distinct test categories that require different tooling and different skills.

We conduct mobile application penetration testing for clients across financial services, healthcare, and consumer-facing sectors. The attack surface varies between iOS and Android, but both platforms share a set of common weaknesses that appear consistently in assessments. Understanding what a mobile test actually examines helps organisations scope it correctly and act on findings in context.

The iOS Attack Surface

iOS applications run in a tighter sandbox than their Android counterparts. Apple's platform controls restrict what an application can access by default, and the App Store review process filters out some categories of obviously malicious behaviour. However, the platform controls do not prevent application developers from making poor security decisions inside their own sandbox. The most common findings in iOS assessments relate to:

• Insecure local data storage -- sensitive data written to plist files, SQLite databases, or the device keychain without appropriate protection class settings
• Weak or absent certificate pinning -- allowing a tester to intercept and modify application traffic using a proxy
• Hardcoded credentials or API keys embedded in the application binary
• Logging of sensitive data to the system log, accessible to other applications or via a connected device
• Insecure inter-application communication via custom URL schemes or shared pasteboard access

Testing iOS applications typically requires a jailbroken device or a specialised testing framework that can instrument the application at runtime. Static analysis of the application binary provides a separate layer of findings that does not require a running device. A thorough iOS assessment combines both approaches.

The Android Attack Surface

Android's open architecture gives testers and developers more flexibility, which cuts both ways. The Android permission model has improved substantially across recent API levels, but many applications still target older API levels and therefore operate under less restrictive permission controls. Common findings in Android assessments include:

• Exported components -- activities, services, broadcast receivers, or content providers that are accessible to other applications on the device without proper permission controls
• Insecure data storage in external storage, shared preferences, or world-readable files
• Weak certificate validation, including applications that accept all certificates regardless of validity
• Hardcoded secrets in the application code or in resource files bundled with the APK
• Insufficient obfuscation, allowing trivial reverse engineering of business logic

Android applications can be decompiled with readily available tooling, which means the source of the compiled application is often recoverable. This changes the threat model: an attacker who downloads your application from the Play Store can read your business logic, identify API endpoints, and extract credentials without ever connecting to your server.

The Server-Side Component Is Not Covered by a Web Test

Mobile applications interact with backend APIs, and those APIs deserve separate testing as part of a mobile assessment. The backend API for a mobile application is often distinct from the web API and may implement different authentication mechanisms, different rate limiting, and different input validation. We regularly find that organisations have well-tested web applications connected to mobile backends that have never been tested at all.

Mobile API testing looks at authentication token handling, whether the API enforces authorisation at the function level rather than just at login, whether it accepts requests from clients that do not identify as the official mobile application, and whether it leaks verbose error messages that assist an attacker in understanding the system. These are not covered by a test of the mobile binary alone.

Fitting Mobile Testing into an Appsec Programme

Mobile penetration testing should occur at least once a year for applications that handle sensitive data, and additionally whenever significant changes are made to the application, the backend API, or the authentication mechanism. A mobile test is not a substitute for a web application test or an API test. Each covers a different surface.

For organisations building mobile applications in-house, the most cost-effective approach is to address common weakness categories during development using a secure development standard such as the OWASP Mobile Application Security Verification Standard, and to use penetration testing to validate that the implementation holds under active testing. This reduces the number of findings in each test cycle and keeps testing focused on the attack surface that has changed.

To discuss mobile application penetration testing for iOS or Android, contact Cyberlinx at info@cyberlinx.com.au.