What We Find on Mobile Application Penetration Tests

Mobile application penetration testing covers the iOS or Android application, the backend APIs it communicates with, and the data it stores on the device. These are three distinct attack surfaces, and findings on mobile assessments regularly span all three. Mobile apps run on devices the organisation does not control, store data in environments accessible to other applications and physical access, and communicate with backend APIs that are often developed with assumptions about the trustworthiness of the mobile client that do not hold under testing.

Insecure local data storage

One of the most consistent mobile findings is sensitive data stored insecurely on the device. Mobile platforms provide multiple storage mechanisms, and not all of them are protected in the way developers assume. SQLite databases that store session tokens, personal data, or transaction history in plaintext. Application log files that capture full request and response payloads, including authentication tokens and personal information. Android shared preferences files containing credentials or tokens stored without encryption. Backup functionality that copies application data — including its databases and files — into locations accessible to other applications or, on Android, to anyone with USB access to the device.

These findings typically require no active exploitation. The data is simply present in accessible locations. An attacker with physical access to an unlocked device, or a malicious application installed on the same device, can retrieve it without any interaction from the user or the target application.

Insecure backend API

Mobile applications communicate with backend APIs that were often developed specifically for the mobile client, and the assumptions built into those APIs frequently do not survive adversarial testing. The most common pattern is that the API trusts the mobile client — if a request contains the right authentication token, the server assumes the request was generated by the genuine application, and applies weaker controls accordingly.

In practice, the API is reachable by anything that can send an HTTP request. Security controls enforced in the mobile interface — preventing users from accessing other users' data, limiting actions to specific account types, enforcing workflow steps — can often be bypassed entirely by constructing requests to the API directly. Rate limiting is absent from many mobile API endpoints that would be attacked by credential stuffing. Input validation applied in the mobile client is not replicated at the server. The delta between what the mobile app will allow and what the API will accept is frequently significant.

Hardcoded credentials and API keys

Mobile application binaries can be decompiled, and the contents are more revealing than developers often expect. API keys embedded in the application to authenticate requests to backend services or third-party providers. Development credentials — sometimes for production systems — included in the binary and not removed before release. Encryption keys used to protect locally stored data embedded in the code that protects the data. Internal API URLs and endpoint structures that are not intended to be public knowledge.

These values are not hidden by compilation or code obfuscation in the absence of deliberate protection steps. We find them consistently in applications that have not been assessed. The remediation is not obfuscation — hardcoded secrets should not be in the binary at all; authentication against backend services should use mechanisms that do not require a long-lived secret in the client.

Certificate validation failures

Mobile applications that communicate over HTTPS should validate the server's TLS certificate to prevent traffic interception by an attacker positioned between the device and the server. A common finding is that certificate validation is disabled or incorrectly implemented — either because validation was turned off for a development environment and never re-enabled, or because the implementation accepts certificates from any issuing authority rather than verifying the expected chain.

Certificate pinning — where the application is configured to accept only a specific certificate or key, rather than any validly issued certificate — provides protection against interception even if an attacker presents a certificate issued by a trusted authority. Many applications handling sensitive financial or personal data do not implement pinning, leaving the traffic vulnerable to interception in environments where an attacker can position themselves between the device and the network, such as a compromised public Wi-Fi access point.

Exported Android components

Android applications are built from components — activities, services, broadcast receivers, and content providers — that can be declared as exported, making them callable by other applications on the device. When components that handle sensitive functionality are exported without appropriate controls, they can be invoked by malicious applications installed on the same device, without any user interaction with the target application.

This misconfiguration leads to findings including authentication bypass — where the activity that opens after a successful login can be launched directly — access to internal content providers that store application data, and triggering of sensitive functions such as payment processing or data export. These misconfigurations are easy to introduce and are not flagged by standard development tools; they require security- focused review of the application's manifest and component architecture to identify.