Mobile Application Security Testing

Starbucks App - API Token in Local Storage = Free Coffee for Attacker

Starbucks app stored API token in plaintext on device. Anyone with phone access (physical or malware) could extract token, replay requests, and load account with someone else’s credit card. Millions of users exposed.

Without mobile security testing:

• Hardcoded API keys/secrets in code (anyone can extract)
• Insecure storage = data in plaintext (SharedPreferences, UserDefaults)
• Weak crypto = easily breakable encryption
• Certificate pinning bypass = man-in-the-middle on SSL
• Root/Jailbreak detection bypass = attackers have full control
• Backend API without security = broken authorization via replay
• No obfuscation = easy reverse engineering

We Test Like Attackers - From Decompile to Exploit

Mobile app security isn’t just code - it’s also storage, API communication, runtime behavior. We test all layers: static analysis (what’s in code), dynamic testing (how it behaves), API security (is backend secure).

What you get:

• Application decompilation and reverse engineering (APK/IPA)
• Code analysis - hardcoded secrets, weak crypto, insecure storage
• Runtime behavior test (Frida hooking, runtime manipulation)
• SSL pinning bypass and MitM on API communication
• Insecure storage test (SharedPreferences, Keychain, SQLite)
• Cryptography analysis (weak algorithms, hardcoded keys)
• Root/jailbreak detection bypass
• Binary protection assessment (obfuscation, anti-tampering)
• Backend API tests (BOLA, broken auth, injection)
• Deep links & URL schemes test
• WebView security (XSS, JavaScript injection)
• Push notifications security
• Detailed report with PoC for each vulnerability
• Recommendations for devs (iOS Swift/Obj-C, Android Kotlin/Java)
• Optional retest after implementing fixes

Who Is It For?

This service is for you if:

• You develop mobile application (iOS/Android) and want tests before publish
• You have app in store and want to check if it’s secure
• Corporate clients require security assessment
• App handles payments, personal data, medical data
• You want to meet OWASP MASVS or compliance (PSD2, fintech)
• Competition had incident and you want to check your security

Android vs iOS Security — How the Platforms Differ and What We Test on Each

Android and iOS both isolate apps from one another, require signed code and offer hardware-backed protection for keys. They do it with different mechanisms, though, and that changes where an app can leak data — which is why we test each platform separately, even within a single project. We do not rank the platforms: in practice the result depends on how your app uses these mechanisms, not on the logo on the phone.

Area	Android	iOS	What the test checks
App isolation	Each app gets its own user ID (UID) and runs in its own process; the kernel enforces the Application Sandbox, so by default apps cannot reach each other’s data	Every third-party app is sandboxed with its own home directory; it can reach other information only through services the system provides, and its entitlements are signed into the app	Whether sensitive data stays inside the sandbox — local files, databases, backups, logs, clipboard
Code signing and distribution	Every app must be signed by the developer; unsigned apps are rejected by Google Play and the package installer, and apps can also be signed by third parties such as alternative stores	All executable code must be signed with an Apple-issued certificate, and Apple verifies the developer’s identity before issuing it; App Store apps are additionally encrypted with FairPlay	Reverse engineering of the APK or IPA, hardcoded secrets, protection against tampering
Key storage	Android Keystore keeps key material out of the app process and can bind it to secure hardware (TEE or Secure Element)	The Secure Enclave is a dedicated subsystem isolated from the main processor, designed to protect sensitive data even if the main kernel is compromised	Whether tokens and keys sit in Keystore / Keychain or in plaintext (SharedPreferences, UserDefaults, plist)
Talking to other apps	App components can be exposed to other apps through intent filters or the exported attribute; some permissions are approved by the user at runtime	Access to user information and system features is governed by declared entitlements; deep links and URL schemes are the typical entry points	Exported components and intents on Android, URL schemes and deep links on both platforms, WebView

The practical difference shows up in the lab. On iOS, App Store builds are FairPlay-encrypted, so the binary has to be decrypted on a jailbroken device — which is why, as the OWASP MASTG testing guide notes, developers often hand the IPA to testers directly, for example through TestFlight. On Android we work on the APK, the manifest and a rooted device. Both platforms are covered by the OWASP MASVS categories listed below, and a joint test of both takes 7-12 business days. To scope a test of your app, contact us.

OWASP MASVS - What We Test

Mobile Application Security Verification Standard

MASVS-STORAGE: Secure Storage

• Sensitive data in plaintext
• Keychain/Keystore misconfiguration
• SQLite without encryption
• Backup data leakage (iTunes/Android backup)
• App data accessible by other apps

MASVS-CRYPTO: Cryptography

• Weak algorithms (DES, MD5, SHA1)
• Hardcoded encryption keys
• Predictable IV/salt
• Custom crypto (always bad)
• Certificate validation issues

MASVS-AUTH: Authentication & Session Management

• Weak password policy
• Biometric bypass
• Session tokens in insecure storage
• No timeout/logout
• Hardcoded credentials

MASVS-NETWORK: Network Communication

• No SSL/TLS
• Certificate pinning missing/bypassable
• Cleartext traffic (HTTP)
• Vulnerable to MitM
• Weak TLS configuration

MASVS-PLATFORM: Platform Interaction

• Insecure WebView configuration (XSS)
• Deep link vulnerabilities
• Clipboard leakage (sensitive data)
• Screen caching (task switcher)
• Logs containing secrets

MASVS-CODE: Code Quality

• No obfuscation
• Debug symbols present
• No anti-tampering
• Insecure IPC (Intents, URL schemes)
• Third-party libraries with CVE

MASVS-RESILIENCE: Anti-Reverse Engineering

• Easy decompilation
• No root/jailbreak detection
• Debugging allowed
• No runtime integrity checks
• Hooking framework detection

Testing Methodology

Static Analysis

iOS (IPA):

• Decompilation (class-dump, Hopper, Ghidra)
• String analysis - hardcoded secrets, URLs, API keys
• Plist analysis - insecure configurations
• Binary analysis - obfuscation level, anti-debugging
• Third-party libraries audit (CocoaPods/Carthage)

Android (APK):

• Decompile (apktool, jadx, JEB)
• AndroidManifest.xml analysis - permissions, exported components
• String analysis - secrets, URLs, tokens
• ProGuard/R8 effectiveness
• Native code analysis (libx.so)
• Third-party libraries (Maven/Gradle dependencies with CVE)

Dynamic Testing

Setup:

• iOS: Jailbroken device, Frida, Objection, SSL Kill Switch
• Android: Rooted device, Frida, Xposed, Burp CA cert

Runtime Analysis:

• SSL pinning bypass
• MitM on API communication (Burp Suite)
• Method hooking (Frida) - bypass auth, modify return values
• Runtime secrets extraction
• File system access
• Memory dump analysis (persistent sensitive data)

Storage Testing:

• iOS: Keychain dump, plist files, SQLite databases
• Android: SharedPreferences, SQLite, internal storage
• Backup extraction (iTunes/adb backup)
• Data wiping test (does delete = delete)

API Testing:

• All endpoints called by app
• Authorization (can I replay token?)
• BOLA/IDOR (changing user ID)
• Rate limiting
• Input validation

Typical Vulnerabilities We Find

1. Hardcoded API Secrets

iOS example:

let apiKey = "AIzaSyD4xX8vQ..." // hardcoded Google API key

Android example:

String API_SECRET = "sk_live_51HxY2..."; // Stripe secret key

Impact: Anyone decompiling app has API access Fix: Secrets in backend, app gets session token

2. Insecure Storage - Tokens in Plaintext

iOS: UserDefaults.standard.set(token, forKey: "auth_token") Android: SharedPreferences.putString("auth_token", token) Impact: Malware/physical access = token theft Fix: iOS Keychain, Android EncryptedSharedPreferences

3. SSL Pinning Bypassable

Problem: App has certificate pinning but can be disabled via Frida Impact: MitM on API communication, credential theft Fix: Proper pinning implementation + anti-tampering

4. Broken Backend Authorization

Scenario: App sends GET /api/user/123/profile Test: Change 123 -> 124 in Burp Vulnerability: Backend doesn’t check if current user can see user 124 Impact: BOLA - access to others’ data

5. Weak Encryption

Example: AES with hardcoded key "mySecretKey12345" Problem: Anyone reverse engineering app has the key Fix: Key derivation (PBKDF2) from user password or secure enclave/keystore

Tools We Use

Static Analysis:

• MobSF (Mobile Security Framework) - automated scanning
• jadx, apktool (Android decompile)
• class-dump, Hopper (iOS decompile)
• Ghidra (binary analysis)

Dynamic Testing:

• Frida (runtime instrumentation & hooking)
• Objection (Frida automation)
• Burp Suite (MitM proxy)
• SSL Kill Switch (iOS pinning bypass)
• Xposed Framework (Android hooking)

Related Glossary Terms

Learn more about key concepts related to this service:

• API
• Authorization
• Backup
• CVE
• Encryption
• OT (Operational Technology)
• TLS
• Vulnerability