Mobile Application Penetration Testing: Client-Side Risks Continue to Grow

Mobile applications contained an average of 6.5 vulnerabilities per project. Across 39 projects, we identified 254 findings, most of them medium-severity issues affecting the client application itself, including APK/AAB packages on Android and IPA packages on iOS. The most common problems are hardcoded credentials and API keys. Other frequent issues include sensitive data stored on the device without encryption and weak client-side security mechanisms. These risks also appear at the top of the updated OWASP Mobile Top 10, which was completely revised for the first time since 2016 and now ranks Improper Credential Usage and Inadequate Supply Chain Security among its leading categories.

Consider a common scenario. Your mobile banking application wants to remember you so that you do not have to log in every time you open it. After authentication, it therefore stores an access token directly on the device. If the token is stored unencrypted and outside the system-protected Android Keystore or iOS Keychain, it remains readable. All it takes is a lost phone, a device handed over for repair, malware on a rooted device or an unencrypted backup. The token is exposed, allowing an attacker to access the account without a password or biometric authentication. This is Improper Credential Usage: a credential that should have been protected by the system vault is left freely accessible in the application’s local storage.

The second risk does not originate in your code at all. The same banking application contains dozens of third-party libraries, ranging from analytics SDKs to payment components. If even one of them becomes the target of a supply chain attack, for example through a malicious update, an attacker can get inside without bypassing any of your own security mechanisms. This is Inadequate Supply Chain Security: you inherit the vulnerabilities of every component added to the application.

The third risk can be demonstrated through another feature of the same application. When making a shared payment, you scan a QR code and the application reads the recipient and payment amount. However, a QR code is merely a data carrier, and an attacker can put virtually anything into it. If the application fails to validate its contents and passes them directly into its internal logic instead of treating them as ordinary payment details, for example into a WebView with access to native functions, a malicious QR code can turn from a payment instruction into executable code. From that point on, it is no longer the user taking action, but the attacker: they can send a predefined amount in your name or extract an access token from the application and take over the account. This is Insufficient Input/Output Validation: the application trusted input that it should have validated first.

What does this mean for CISOs?

If your company develops a mobile application, the application installed on your users’ devices is part of your attack surface. Do not test only the backend services; test the application that people actually use.