Mobile Application Security Testing: A Practical Guide for iOS and Android

Mobile Apps: The Largest Attack Surface in Indian Tech

Indian users do more on mobile than any other market, UPI payments, banking, healthcare, government services, e-commerce, work apps. The result: Indian mobile applications are the largest single attack surface for cybercrime targeting Indian users.

The threat is amplified by the unique characteristics of mobile apps: (1) the app binary is fully available to attackers (anyone can download and decompile it); (2) sensitive data persists on the device (offline cache, keychain, shared preferences); (3) the device itself may be rooted/jailbroken/compromised; (4) backend APIs are the actual data store, but apps act as visible API documentation; (5) third-party SDKs introduce supply chain risk.

A thorough mobile pentest looks at all of these surfaces. Cheap mobile 'pentests' that just run a static scanner on the APK and report missing protections are nowhere near comprehensive. Real mobile security testing uses OWASP MASVS as the framework and the OWASP Mobile Security Testing Guide (MSTG) as the methodology playbook.

OWASP Mobile Top 10: What Every Indian App Should Defend Against

OWASP Mobile Top 10 is the practical priority list of mobile app risks. The 2024 revision (current as of 2026):

• M1: Improper Credential Usage, hardcoded credentials, weak authentication, insufficient password complexity
• M2: Inadequate Supply Chain Security, vulnerable third-party SDKs, unsigned libraries, malicious dependencies
• M3: Insecure Authentication/Authorization, broken session management, missing MFA, broken access controls
• M4: Insufficient Input/Output Validation, injection flaws, broken deserialization, output encoding issues
• M5: Insecure Communication, missing TLS, weak ciphers, insufficient certificate pinning
• M6: Inadequate Privacy Controls, leaking PII in logs, excessive permissions, no consent flows
• M7: Insufficient Binary Protections, no jailbreak/root detection, no anti-tampering, no obfuscation for high-value apps
• M8: Security Misconfiguration, debug builds in production, overly permissive AndroidManifest/Info.plist, exported components
• M9: Insecure Data Storage, sensitive data in SharedPreferences/UserDefaults, plaintext databases, accessible cache files
• M10: Insufficient Cryptography, weak algorithms, hardcoded keys, poor key management

Phase 1: Static Analysis (Decompiling and Reading the Binary)

Every mobile pentest starts with static analysis. The app binary (IPA for iOS, APK for Android) is decompiled and reviewed for security issues without running the app.

Android Static Analysis

Android apps are easier to reverse-engineer than iOS. Tools like apktool, jadx, and Bytecode Viewer decompile the APK back to readable Java/Kotlin code. We review: AndroidManifest.xml (exported components, permissions, intent filters), resources (hardcoded strings, embedded credentials, API endpoints), classes.dex (decompiled source code for security-sensitive paths), native libraries (so files for additional code), assets and raw resources, signing certificate.

iOS Static Analysis

iOS is harder because the binary is encrypted on App Store, requiring a jailbroken device to dump the unencrypted Mach-O binary. Once dumped, tools like Hopper, IDA, Ghidra, class-dump, and strings provide insight. We review: Info.plist (URL schemes, ATS exceptions, permissions), embedded plists and certificates, strings (hardcoded credentials, API endpoints), class-dump output for method signatures, code signing entitlements.

Common Static Findings

From our Indian customer engagements: hardcoded AWS access keys (5-10% of apps), hardcoded API tokens (15-25%), plaintext credentials for backend services (5-15%), debug logging that leaks PII (30-40%), insufficient root/jailbreak detection (60-70%), missing certificate pinning code (40-50%), commented-out code revealing future features or weaknesses (10-15%).

Phase 2: Dynamic Analysis (Running the App with Instrumentation)

Dynamic analysis runs the app on a controlled jailbroken/rooted device with runtime instrumentation. This phase finds vulnerabilities that only appear at runtime, broken authentication flows, weak session management, vulnerable IPC, broken cryptography implementations.

Primary tools: Frida for runtime function hooking and method tracing, Objection for high-level operations, Burp Suite with iOS/Android proxy for HTTP traffic inspection, mitmproxy for advanced protocol manipulation, Drozer for Android IPC testing, iOS Hooking via Theos / Cydia substrate for older iOS.

Certificate Pinning Bypass

Many Indian banking apps implement certificate pinning to prevent traffic inspection. Our methodology: (1) attempt direct proxy connection, observe pinning failure; (2) use SSL Kill Switch 2 on iOS or Frida scripts on Android to bypass standard pinning libraries (TrustKit, OkHttp, AFNetworking); (3) for custom pinning implementations, manually hook the specific certificate validation function via Frida. Bypassing pinning lets us see and modify the actual API traffic, usually the highest-value testing surface.

Backend API Testing

Once we can see API traffic, the backend testing follows standard OWASP API Top 10 methodology. We test for: broken object-level authorization (changing IDs in API calls to access other users' data), broken function-level authorization, mass assignment, insufficient rate limiting, JWT vulnerabilities, race conditions, business logic flaws. API testing is often where critical findings come from, the app is just a UI for backend APIs.

Real Vulnerabilities We Find Every Week in Indian Mobile Apps

From our practice of testing Indian fintech, healthtech, government and consumer mobile apps:

• Banking app with broken OTP flow: OTP was generated server-side but verified client-side. Modifying the response in the mobile app bypassed OTP entirely.
• Healthcare app with patient ID enumeration: Patient records were keyed by sequential integers. Iterating IDs in API calls retrieved all patient records.
• Fintech app with insecure deep linking: Custom URL scheme accepted unauthenticated commands, allowing crafted SMS to transfer money.
• E-commerce app with insecure direct object reference: Modifying the order ID in any API call retrieved any user's complete order history and address.
• Government app with hardcoded API key: The API key gave full admin access to the backend. Single download of the APK gave attackers everything.
• Insurance app with no certificate pinning: Customer data could be intercepted on public Wi-Fi (airports, cafes).
• Loan app with weak biometric integration: 'Biometric login' was UI-only; the actual authentication used a static token stored in plaintext.

How to Scope a Meaningful Mobile Pentest

Many Indian businesses scope mobile pentests too narrowly and miss the most important attack surfaces. A proper mobile pentest scope includes:

• The mobile app itself (iOS and/or Android): All user roles tested, all major features covered, decompilation + dynamic analysis on rooted/jailbroken devices.
• Backend APIs the app uses: Often the highest-value target. API testing typically takes 40-60% of pentest time.
• Authentication flows: Login, OTP, biometric, social login, password reset, account recovery, session management.
• Payment flows (if applicable): UPI integration, card payments, wallet operations, transaction signing.
• In-app purchase / receipt validation: Critical for any app with paid features.
• Third-party SDKs: Analytics, ads, crash reporting, social login, many SDKs introduce vulnerabilities or leak data.
• Push notification handling: Deep links from push notifications often bypass authentication checks.
• Offline data and caching: What data persists when offline, how is it protected, can it be tampered with.

Codesecure Mobile Pentest Methodology (OWASP MASVS L2)

Our mobile pentest engagements follow the OWASP MASVS L2 framework (which is the appropriate level for apps handling sensitive data, financial, healthcare, government). MASVS L2 has 8 control categories: architecture, data storage, cryptography, authentication, network communication, platform interaction, code quality, resilience.

A typical Codesecure mobile pentest engagement: Day 1-2 static analysis of iOS and Android binaries, Day 3-5 dynamic testing with Frida/Objection on jailbroken iPhone and rooted Android device, Day 4-7 backend API testing through the mobile app proxy, Day 7-8 business logic and chained vulnerability testing, Day 9-10 reporting and walkthrough. Total: 8-10 business days for comprehensive coverage of iOS + Android + backend.