Mobile applications present a fundamentally different security challenge than web applications. The code runs on a device you do not control, communicates over networks you cannot trust, and stores data in environments shared with potentially malicious apps. Web security experience translates only partially.
The attack surface of a mobile app spans the binary itself, the communication channel, the backend APIs, and the device's local storage. Testing all four layers requires different tools and techniques.
Setting Up Your Testing Environment
Before testing anything, you need the right infrastructure.
Android:
- A rooted device or emulator with Magisk for root access
- Frida for runtime instrumentation
- Objection (built on Frida) for common mobile security tasks
- jadx for decompiling APKs to readable Java/Kotlin
- Burp Suite or mitmproxy as an intercepting proxy
- ADB for device communication
iOS:
- A jailbroken device (emulators have limited utility for security testing)
- Frida and Objection
- class-dump or dsdump for extracting Objective-C class information
- Hopper or Ghidra for binary analysis
- SSL Kill Switch 2 or similar for bypassing certificate pinning
Both platforms:
- A wireless access point you control for traffic interception
- The target application's IPA/APK file
Binary Analysis
Start by examining what the app reveals about itself before it even runs.
Android APK analysis:
# Decompile the APK
jadx -d output/ target.apk
# Check AndroidManifest.xml for:
# - Exported components (activities, services, receivers, providers)
# - Permission requests (does it need what it asks for?)
# - Backup allowance (android:allowBackup="true" leaks data)
# - Debuggable flag (should never be true in production)
# - Network security config (cleartext traffic settings)
iOS binary analysis:
- Check for PIE (Position Independent Executable), ARC, and stack canary protections
- Look for hardcoded strings (API keys, URLs, credentials)
- Identify third-party frameworks and their versions
- Check Info.plist for App Transport Security exceptions
Hardcoded secrets are more common in mobile apps than you would expect. Developers embed API keys, analytics tokens, and sometimes actual credentials directly in the binary, assuming decompilation is too hard for attackers. It is not.
Data Storage Testing
Mobile apps store data in ways web apps never do. Each storage mechanism has different security properties.
Shared Preferences / UserDefaults. Plaintext key-value storage. Never appropriate for sensitive data, but frequently used for authentication tokens, user profiles, and even passwords.
SQLite databases. Often unencrypted. Check for sensitive data in local databases. On rooted/jailbroken devices, these files are trivially accessible.
Keychain (iOS) / Keystore (Android). The correct place for sensitive data, but only if used properly. Check Keychain accessibility levels — data stored with kSecAttrAccessibleAlways is accessible even when the device is locked.
Application logs. Developers leave debug logging in production builds. On Android, logcat captures everything. Check for sensitive data in log output.
Clipboard. Sensitive data copied to the clipboard is accessible to every app on the device. Check if the app uses the clipboard for passwords or tokens.
Screenshot/background caching. Both iOS and Android capture screenshots when apps go to the background. If the app displays sensitive data, that data might be cached as an image.
Network Communication Testing
Certificate pinning bypass. Most security-conscious apps implement certificate pinning, which prevents traffic interception with a proxy. Testing requires bypassing this:
- Frida scripts that hook SSL verification functions
- Objection's
android sslpinning disableorios sslpinning disable - Custom Frida scripts for non-standard pinning implementations
Once you can intercept traffic, test the API layer using the same techniques as web API testing. BOLA, authentication, authorization — they all apply.
Cleartext traffic. Check if the app communicates over HTTP for any requests. Android's Network Security Config and iOS's App Transport Security should prevent this, but exceptions are common.
Certificate validation. Beyond pinning, check if the app validates certificates at all. A custom TrustManager that accepts all certificates is a critical finding.
Runtime Manipulation
Frida enables real-time modification of application behavior. This is where mobile testing gets interesting.
Bypassing root/jailbreak detection. Most apps detect compromised devices and refuse to run. Frida can hook the detection functions and force them to return false.
Modifying function return values. Authentication checks, license validations, and feature flags can be bypassed by hooking the relevant functions and changing their return values.
Extracting encryption keys. If the app encrypts data locally, hook the cryptographic functions to capture keys, IVs, and plaintext.
Bypassing biometric authentication. Some implementations only check a local boolean flag rather than binding authentication to server-side tokens. Frida can flip that flag.
Inter-Process Communication Testing
Mobile apps communicate with other apps and system services through IPC mechanisms that can be abused.
Android:
- Test exported Activities for unauthorized access
- Check Intent filters for data injection
- Test Content Providers for SQL injection and path traversal
- Verify Broadcast Receivers do not accept intents from untrusted sources
iOS:
- Test URL schemes for input validation
- Check Universal Links configuration
- Test app extensions for data leakage
- Verify that pasteboard usage is appropriate
Third-Party Library Risks
Mobile apps bundle their dependencies directly, unlike web apps that might load them from CDNs. This means vulnerable library versions persist until the app is updated.
Common issues:
- Outdated versions of networking libraries with known vulnerabilities
- Analytics SDKs that collect excessive data
- Ad SDKs that introduce their own security and privacy risks
- Abandoned libraries with no security maintenance
Identifying third-party libraries from a binary requires examining the app's frameworks directory (iOS) or library references (Android). Version identification is harder but possible through string analysis and binary signatures.
Automation and CI/CD Integration
Some mobile security checks can be automated:
- Static analysis of the binary (MobSF is a solid open-source option)
- Dependency vulnerability scanning of identified libraries
- Network security configuration validation
- Hardcoded secret detection
- Permission analysis
Runtime testing (Frida-based manipulation, dynamic analysis) is harder to automate but can be scripted for regression testing of specific vulnerabilities.
How Safeguard.sh Helps
Safeguard.sh brings supply chain visibility to mobile applications. Mobile apps bundle dozens of third-party libraries, and each one is a potential vulnerability. Safeguard.sh's SBOM tracking identifies every component in your mobile app's dependency tree, monitors for newly disclosed vulnerabilities, and enforces policies that prevent shipping apps with known-vulnerable libraries. This is particularly valuable for mobile apps because users are slow to update, which means a vulnerable library in a shipped app can remain exploitable for months.