Mobile App Security Testing: What Breaks in iOS and Android Applications

Mobile applications are fundamentally different from web applications, and the security testing they require reflects that difference. When you ship a web application, the code runs on servers you control. When you ship a mobile application, you hand the entire client-side codebase to every user who downloads it. They own the device. They control the environment. And if they are motivated, they can decompile your binary, intercept your traffic, manipulate your runtime, and extract every secret you embedded in the code.

This is not a theoretical concern. Mobile applications routinely ship with hardcoded API keys, disabled certificate validation, sensitive data stored in plaintext on the device, and backend APIs that trust whatever the client sends without server-side validation. The app store review process does not catch these issues. Automated scanners miss most of them. And the consequences range from data theft to full account takeover.

Why mobile apps need dedicated security testing

Web application security testing methodologies do not transfer directly to mobile. The threat model is different. The attack surface is different. The tools are different. Here is why mobile applications require their own testing discipline.

The client is hostile territory

In web security, the browser is an untrusted client, but the server controls what code is delivered and executed. In mobile security, the entire application binary lives on a device the attacker controls. They can jailbreak or root the device, attach a debugger, modify the application at runtime, and inspect every byte of storage. Any logic that runs client-side, any secret stored locally, any check performed on the device, can be observed and subverted.

Reverse engineering is straightforward

Android applications are distributed as APK files, which are essentially ZIP archives containing Dalvik bytecode. Tools like jadx and apktool decompile these back into near-original Java or Kotlin source code in seconds. iOS applications are compiled to native ARM binaries, which are harder to reverse engineer but far from impossible. Tools like Hopper, Ghidra, and class-dump extract class structures, method signatures, and string constants. Obfuscation slows this process down but never stops it.

Local storage is an attack surface

Mobile applications store data locally far more aggressively than web applications. Offline functionality, caching, user preferences, authentication tokens, and cached API responses all end up on the device file system. On a rooted or jailbroken device, all of this data is accessible. On a non-rooted device, physical access combined with a backup extraction can still expose it. The question is not whether sensitive data will be stored locally, but whether it is stored securely.

Network communication is interceptable

Every API call a mobile application makes traverses a network the attacker can control. Setting up a man-in-the-middle proxy takes minutes. If the application does not implement certificate pinning, or implements it incorrectly, every request and response is visible in plaintext. This exposes API structures, authentication tokens, business logic, and data flows that the developer assumed were hidden inside the compiled binary.

The OWASP Mobile Top 10

The OWASP Mobile Top 10 provides the industry-standard framework for mobile application security risks. It covers the categories of vulnerabilities that appear most frequently in real-world mobile penetration tests. Here is each risk category and what it means in practice.

The critical point is that most of these vulnerabilities exist entirely outside the scope of traditional web application security testing. A web pentest will test the API endpoints. It will not test what the mobile binary does with the API responses, how it stores data locally, whether it leaks information through the device clipboard, or whether its certificate pinning can be bypassed. These require dedicated mobile security testing.

Static analysis: what we learn before running the app

Static analysis examines the application binary without executing it. This phase reveals architectural decisions, embedded secrets, and security controls before we ever interact with a running application. For many mobile apps, static analysis alone exposes critical vulnerabilities.

Decompilation and source code review

For Android applications, we decompile the APK using tools like jadx to recover Java/Kotlin source code. The output is remarkably readable. Class names, method names, string constants, and application logic are typically preserved almost verbatim. We review this decompiled source for hardcoded secrets, insecure cryptographic implementations, disabled security controls, and business logic that should not be visible to the client.

For iOS applications, we use class-dump to extract Objective-C class interfaces and Ghidra for deeper binary analysis. While Swift and Objective-C compile to native ARM code that is harder to reverse than Dalvik bytecode, the class structure, method signatures, and string constants are still accessible. Enough of the application logic is recoverable to identify architectural weaknesses and security flaws.

Hardcoded secrets

This is one of the most common findings in mobile penetration tests, and one of the most impactful. Developers embed API keys, secret tokens, database connection strings, encryption keys, and third-party service credentials directly in the application code. They assume the compiled binary obscures these values. It does not.

A simple string search through a decompiled Android APK routinely reveals AWS access keys, Firebase configuration details, payment gateway secrets, push notification certificates, and internal API endpoints. On iOS, the same information appears in the application's Info.plist, embedded frameworks, and string constants extracted from the binary. These secrets provide direct access to backend infrastructure and third-party services.

Certificate pinning implementation review

During static analysis, we examine how the application implements certificate pinning, if it does at all. We look for the pinning configuration in Android's network_security_config.xml, in iOS's Info.plist App Transport Security settings, and in any third-party networking libraries like OkHttp, Alamofire, or TrustKit. We assess whether the pinning is correctly configured, whether it covers all domains the application communicates with, and whether there are obvious bypass paths such as debug flags that disable pinning or fallback behaviors that accept any certificate when pinning fails.

Dynamic analysis: testing the running application

Static analysis tells us what the application is built to do. Dynamic analysis tells us what it actually does at runtime, including behaviors that are not apparent from the code alone. This phase involves running the application on a controlled device while intercepting traffic, manipulating data, and observing how the app and its backend respond.

Traffic interception with proxy tools

We route all application traffic through an interception proxy like Burp Suite or mitmproxy. This reveals every API call the application makes, the data it sends, the responses it receives, and the authentication mechanisms it uses. We examine API endpoints for authorization flaws, excessive data exposure, and missing input validation, the same methodology we apply in dedicated API security testing, but from the mobile client perspective.

Traffic interception also reveals communication with third-party services that the application makes without the user's knowledge: analytics platforms, crash reporting services, advertising networks, and social media SDKs. We assess what data is transmitted to these services and whether it includes PII or sensitive business information.

Runtime manipulation with Frida

Frida is the cornerstone tool for mobile dynamic analysis. It is a dynamic instrumentation framework that lets us inject JavaScript into a running application process, hooking any function, modifying any variable, and intercepting any method call at runtime. The power this provides is difficult to overstate.

With Frida, we can bypass jailbreak and root detection by hooking the detection functions and forcing them to return false. We can disable certificate pinning by hooking the TLS validation functions. We can intercept encryption and decryption calls to see plaintext data before it is encrypted or after it is decrypted. We can modify function return values to bypass client-side license checks, feature gates, and authorization logic. If the application performs any security check on the client side, Frida can subvert it.

Certificate pinning bypass in practice

Certificate pinning is a legitimate security control that prevents traffic interception. During a penetration test, we need to bypass it to assess the API layer. There are multiple approaches depending on the implementation. Frida scripts like objection's ssl pinning disable command hook the platform's TLS validation functions. Magisk modules on Android can install custom trust stores at the system level. On iOS, SSL Kill Switch patches the Security framework to accept any certificate. For applications using custom pinning libraries, we write targeted Frida scripts that hook the specific validation functions those libraries use.

The ease with which pinning can be bypassed is itself a finding. If a motivated attacker with thirty minutes of setup time can disable your pinning implementation, it provides security in depth but not security in isolation. The API layer must still be secure independent of client-side controls.

iOS-specific testing

iOS provides a strong security model with hardware-backed encryption, strict sandboxing, and mandatory code signing. But the security of an individual application depends on how well the developer uses these platform features. Many do not use them correctly.

Keychain storage analysis

The iOS Keychain is the platform's secure credential storage mechanism, backed by the Secure Enclave on modern devices. When used correctly, it provides hardware-level protection for sensitive data like authentication tokens, encryption keys, and passwords. When used incorrectly, it provides a false sense of security.

We test Keychain usage for several common mistakes. Accessibility flags control when Keychain items are accessible. Items stored with kSecAttrAccessibleAlways are accessible even when the device is locked, defeating the purpose of Keychain storage. Items stored with kSecAttrAccessibleAfterFirstUnlock are accessible any time after the first unlock since boot, which is nearly always. The most secure option, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, is rarely used. We also check whether Keychain items are set to synchronize via iCloud Keychain, which means they are transmitted to Apple's servers and accessible on every device linked to the same Apple ID.

App Transport Security configuration

App Transport Security (ATS) enforces HTTPS connections by default on iOS. But developers can and frequently do add exceptions. The most egregious exception is NSAllowsArbitraryLoads, which disables ATS entirely and allows plaintext HTTP connections to any domain. We also find per-domain exceptions that downgrade TLS requirements for specific backends, often because the backend server uses an outdated TLS configuration and the developer chose to weaken the client rather than fix the server.

We extract the Info.plist from the application bundle and review every ATS exception. Each exception is a deliberate weakening of the platform's transport security, and each one needs justification.

Jailbreak detection bypass

Many iOS applications implement jailbreak detection to refuse running on compromised devices. The detection techniques typically check for the existence of common jailbreak files like /Applications/Cydia.app or /private/var/stash, test whether the application can write outside its sandbox, check for the presence of a fork() capability, or attempt to open specific URL schemes associated with jailbreak tools.

We bypass these checks to test the application in an environment where we have full file system access and can attach debugging tools. Bypass methods range from simple Frida scripts that hook the detection functions to more sophisticated approaches that intercept file system calls and return false negatives. The purpose is not to prove that jailbreak detection is useless, it does raise the bar, but to test what happens when it is bypassed, because real attackers will bypass it.

Android-specific testing

Android's open ecosystem provides more flexibility than iOS, but that flexibility comes with a larger attack surface. The permission model, inter-process communication mechanisms, and storage architecture all introduce security considerations that do not exist on iOS.

Shared preferences and local storage

Android's SharedPreferences API is the most common local storage mechanism, and it is frequently misused. SharedPreferences stores data as XML files in the application's private directory. On a rooted device, these files are directly readable. We routinely find authentication tokens, session identifiers, user credentials, and personal data stored in SharedPreferences in plaintext.

The Android Keystore system provides hardware-backed cryptographic key storage, analogous to the iOS Keychain. But many developers store sensitive data in SharedPreferences, internal storage files, or SQLite databases without encrypting it, either because they are unaware of the Keystore or because they assume the application sandbox provides sufficient protection. On a rooted device or through a backup extraction, the sandbox provides no protection at all.

Content providers

Content providers are Android's mechanism for sharing data between applications. A content provider that is exported (accessible to other applications) without proper permission checks exposes its data to any application on the device. We test every exported content provider to determine what data it exposes and whether it enforces appropriate access controls.

The risk is not hypothetical. A malicious application installed on the same device can query an exported content provider and extract whatever data it serves: contacts, messages, authentication tokens, or application-specific data. If the content provider supports write operations, the malicious application can also modify data, potentially injecting malicious content or altering application state.

Exported activities and broadcast receivers

Android's intent system allows inter-application communication through activities, broadcast receivers, and services. Components that are declared as exported in the AndroidManifest.xml can be invoked by any application on the device. We test every exported component for unintended functionality.

Common findings include exported activities that bypass authentication flows, allowing another application to launch directly into a logged-in state or access restricted screens. Exported broadcast receivers that trigger privileged operations when they receive crafted intents. Deep links that are not properly validated, allowing an attacker to craft URLs that trigger unintended navigation or pass malicious parameters to application logic.

Root detection bypass

Like jailbreak detection on iOS, root detection on Android attempts to identify compromised devices. Detection methods include checking for the su binary, testing for root management apps like Magisk or SuperSU, verifying the system partition integrity, checking build properties, and testing whether the application can execute privileged commands.

Modern root solutions like Magisk are specifically designed to hide root from detection. MagiskHide (and its successors) can conceal the root status from individual applications. Frida scripts can hook detection functions at runtime. The arms race between root detection and root concealment is ongoing, but in a penetration test context, we consistently bypass root detection to access the device's file system and perform thorough analysis.

API security from the mobile perspective

The most critical vulnerabilities in mobile applications often are not in the mobile binary at all. They are in the backend API that the mobile application communicates with. Mobile applications create unique API security challenges because developers frequently implement security logic on the client side and assume the server does not need to duplicate it.

Missing server-side validation

This is the pattern we find most often and the one with the highest impact. The mobile application enforces business rules on the client: maximum order quantities, price validation, role-based access to features, input format restrictions. The API trusts whatever the client sends. An attacker who bypasses the client (using a proxy, a modified binary, or direct API calls) can submit requests that the legitimate application would never generate, and the server processes them without question.

Client-side authorization

Mobile applications frequently implement feature gating on the client side. The API returns the full data set for every user, and the mobile application filters what to display based on the user's role or subscription tier. A premium feature that is "hidden" in the UI is fully accessible through direct API calls. Administrative functions that are not rendered in the standard user interface still respond to API requests from standard user tokens.

During testing, we compare what the mobile application shows the user with what the API actually returns. The difference between these two sets of data, what we call the "hidden surface," often contains the most sensitive information and the most critical business functionality. If the API returns admin-level data to a standard user's token, the client-side filtering is not security; it is presentation.

Token handling and session management

Mobile applications handle authentication tokens differently than web applications. Tokens are stored locally for extended periods to avoid forcing users to log in repeatedly. Refresh tokens often have long or indefinite lifespans. Token revocation is difficult because mobile applications may be offline when revocation occurs. We test whether the backend actually validates token expiration, whether refresh tokens can be reused after rotation, and whether token revocation is enforced for all subsequent requests. Weak token handling is covered in detail in our API security testing guide.

Local data storage vulnerabilities

Mobile applications accumulate sensitive data on the device over time. Even applications that appear stateless in their design cache responses, store user preferences, and maintain local databases that contain far more information than the developers intended.

SQLite databases

Many mobile applications use SQLite for local data persistence. On a rooted or jailbroken device, these database files are directly accessible. We extract and analyze every SQLite database the application creates, looking for authentication tokens, personal data, financial information, cached API responses containing sensitive data, and application state that reveals business logic. We also check whether the databases use encryption (like SQLCipher) and, if so, whether the encryption key is hardcoded in the application binary.

File system storage

Beyond databases, applications write data to the file system as cached images, downloaded documents, temporary files, and log files. We inspect the entire application sandbox directory for sensitive data. Common findings include cached user profile images that persist after logout, downloaded documents that are not encrypted at rest, and temporary files that contain authentication tokens or session data.

Clipboard exposure

When users copy sensitive information within an application, such as passwords, account numbers, or two-factor authentication codes, that data goes to the system clipboard, where it is accessible to every other application on the device. We test whether the application allows copying of sensitive fields and whether it clears the clipboard after a timeout. On Android, clipboard data persists until replaced. On iOS 14 and later, applications that read the clipboard trigger a notification, but the data is still accessible.

Screenshot and background state exposure

Both iOS and Android capture screenshots of the application when it enters the background, displaying them in the task switcher. If the application is showing sensitive information, that data is captured in an image that persists on the device file system. We test whether the application implements screenshot protection by overlaying a blank or blurred view when entering the background state. We also test whether the application prevents screen recording and screen capture while sensitive data is displayed.

Authentication and session management in mobile apps

Mobile authentication flows have unique characteristics that create security challenges not present in web applications.

Biometric authentication bypass

Many applications implement fingerprint or face recognition as an authentication mechanism. The critical question is what the biometric check actually protects. In a secure implementation, biometric authentication unlocks a cryptographic key stored in the Secure Enclave (iOS) or hardware-backed Keystore (Android), and that key is required to decrypt the authentication token. In a weak implementation, the biometric check simply sets a boolean flag, and the authentication token is accessible regardless of whether the biometric check passes. We test which model the application uses and whether the biometric check can be bypassed at the API level.

Deep link authentication bypass

Applications that use deep links for authentication flows (password reset, magic link login, OAuth callbacks) must validate these links carefully. We test whether deep links can be intercepted by a malicious application registered for the same URL scheme, whether the tokens in deep links are properly validated and expire after use, and whether the authentication flow can be replayed by re-using a captured deep link.

Session persistence after logout

When a user logs out, the mobile application should invalidate the authentication token on the server, delete the local token, clear cached data, and remove any sensitive information from local storage. We test each of these steps independently. A common finding is that the application deletes the local token but does not invalidate it on the server, meaning a previously captured token remains valid after the user believes they have logged out.

Push notification security

Push notifications introduce a communication channel that is separate from the application's primary API. This channel has its own security considerations that are frequently overlooked.

Sensitive data in notification payloads. Push notifications often contain message previews, transaction details, authentication codes, or other sensitive information. This data is displayed on the device lock screen by default, visible to anyone with physical access. Even when the device is unlocked, notifications are processed by the operating system before the application receives them, meaning the application cannot control how notification data is stored or displayed at the OS level.

Push token registration and management. When a device registers for push notifications, it receives a push token that uniquely identifies it. If the server-side push notification system does not properly associate push tokens with authenticated user sessions, an attacker can register their device to receive another user's notifications. We test whether push tokens are properly bound to user accounts and whether token registration requires authentication.

Notification content manipulation. If the push notification infrastructure uses unencrypted channels or does not validate message integrity, notification content can potentially be spoofed. We test whether the application verifies the authenticity of push notification content before acting on it, especially for notifications that trigger in-app actions like navigation to specific screens or execution of business logic.

Third-party SDK risks

A typical mobile application includes dozens of third-party SDKs for analytics, crash reporting, advertising, social media integration, payment processing, and other functionality. Each SDK is code that runs with the same permissions as your application, has access to the same data, and communicates with external servers you do not control.

Analytics and crash reporting SDKs

Analytics SDKs collect usage data, which often includes more information than the developer intended. Screen names, user interaction patterns, device identifiers, and even input field contents can be transmitted to third-party analytics servers. Crash reporting SDKs capture application state at the time of a crash, which can include memory dumps containing authentication tokens, personal data, and API responses. We review what data each SDK collects and transmits, and whether it includes sensitive information.

Advertising SDKs and data harvesting

Advertising SDKs are among the most invasive third-party components. They commonly collect device identifiers, location data, installed application lists, network information, and user behavior patterns. Some advertising SDKs have been found to perform clipboard sniffing, accessing whatever the user last copied. We identify all advertising SDKs in the application and assess what data they access and transmit.

Outdated and vulnerable SDKs

Third-party SDKs do not update themselves. When a vulnerability is discovered in an SDK, every application that includes it remains vulnerable until the developer updates the SDK and releases a new version of the application. We check every third-party library and SDK against known vulnerability databases. It is common to find applications shipping with SDK versions that have known, publicly disclosed security vulnerabilities, sometimes years old.

Certificate pinning: implementation and testing

Certificate pinning deserves extended discussion because it sits at the intersection of legitimate security control and penetration testing methodology. Understanding what pinning protects against, and what it does not, is essential for making informed security decisions.

What certificate pinning protects

Certificate pinning defends against man-in-the-middle attacks where an attacker has compromised or installed a trusted certificate authority on the device. Without pinning, an attacker who installs a custom CA certificate (through device management profiles, social engineering, or physical access) can intercept and decrypt all HTTPS traffic. With pinning, the application only trusts specific certificates or public keys, rejecting connections even if the presented certificate is signed by a trusted CA.

Implementation approaches

On Android, the recommended approach is the network_security_config.xml file, which declaratively specifies which certificates to trust for which domains. This is straightforward to implement but applies only to connections made through Android's standard networking stack. Applications using custom TLS implementations, native code, or third-party networking libraries may need additional pinning configuration.

On iOS, pinning is typically implemented through URLSessionDelegate methods that validate the server certificate against a stored reference, or through third-party libraries like TrustKit that provide a declarative pinning configuration. Apple does not provide a built-in declarative pinning mechanism equivalent to Android's network_security_config.

Common pinning mistakes

Pinning only the leaf certificate. When the certificate is rotated (which happens at least annually for publicly trusted certificates), the application breaks until it is updated. Pinning the intermediate CA or the public key provides more resilience to certificate rotation.

Not including backup pins. If the pinned certificate is compromised or needs emergency rotation, an application without backup pins will be unable to connect to the server until a new version is deployed and installed by every user. This can take weeks through app store distribution.

Pinning in debug but not release builds. Build configurations that disable pinning for development convenience sometimes ship to production. We verify that the release build configuration enforces pinning.

Incomplete domain coverage. Applications that pin their primary API domain but not their CDN, analytics, authentication, or third-party service domains leave those connections vulnerable to interception.

Mobile app security testing checklist

This checklist covers the essential testing areas for a thorough mobile security assessment. Whether you are preparing for an external penetration test or conducting internal security reviews, these are the areas that matter most.

What happens after a mobile security test

The output of a mobile security assessment is a detailed report covering every finding with its severity, evidence (including screenshots, request/response pairs, and Frida scripts), and specific remediation guidance. Findings are prioritized based on real-world exploitability, not theoretical risk.

The most common critical findings fall into three categories. Hardcoded secrets that provide direct access to backend infrastructure or third-party services. Missing server-side validation that allows client-side security controls to be bypassed entirely. Insecure local storage that exposes authentication tokens and personal data on compromised devices.

Remediation typically requires changes across the full stack: the mobile binary, the backend API, and the deployment pipeline. Secrets need to be rotated and removed from the codebase. Server-side validation needs to duplicate every business rule that currently exists only on the client. Local storage needs to use platform-provided secure storage mechanisms with appropriate access controls.

Because mobile application updates must go through the app store review process, remediation timelines are longer than for web applications. A critical web vulnerability can be patched within hours. A critical mobile vulnerability requires a new binary build, app store submission, review approval, and then waiting for users to update. This delay makes it even more important to find and fix these issues proactively through regular security testing rather than discovering them after exploitation.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.