iOS and Android Mobile App Penetration Testing
Most mobile apps ship with the same class of vulnerabilities: hardcoded API keys buried in the binary, sensitive data cached to unprotected storage, and backend APIs that trust the client far more than they should. Our mobile penetration testing engagements find these before attackers do, on iOS, Android, or both, and produce the technical evidence your security and compliance teams need.
Certified ethical hackers bring platform-specific depth, iOS and Android scoped and tested independently.
What We Test on iOS
iOS imposes stricter sandboxing than Android, but that doesn’t make the attack surface small. Our iOS assessment covers:
- Keychain misconfigurations: tokens and credentials stored with
kSecAttrAccessibleAlwaysor equivalent, remaining accessible when the device is locked or via unencrypted backups - Data Protection API misuse: files written to unprotected NSFileProtection classes, persisting across reboots and accessible under forensic imaging
- URL scheme and Universal Link abuse: deep links that bypass authentication steps or leak session context to third-party apps
- Pasteboard exposure: sensitive values copied to the system clipboard without restriction, readable by any foregrounded app
- Binary protection checks: stack canary presence, PIE enforcement, and ARC usage reviewed directly from the IPA without requiring source code
- Runtime manipulation: Frida-based hooking to bypass biometric checks, jailbreak detection routines, and SSL pinning without binary patching
- Third-party SDK risks: analytics and advertising SDKs exfiltrating PII or transmitting data over insufficiently encrypted channels
- ATS exception review:
NSAllowsArbitraryLoadsand per-domain overrides examined inInfo.plistfor downgrade risk
What We Test on Android
Android’s open architecture produces a wider IPC (inter-process communication) attack surface. Our Android assessment covers:
- Exported components: Activities, Services, Broadcast Receivers, and Content Providers reachable without declared permissions, mapped using Drozer
- Intent injection: manipulating implicit intents to redirect sensitive data flows or trigger unintended privileged operations
- Insecure SharedPreferences and external storage: credentials, tokens, or PII written in cleartext to world-readable locations or unexcluded backup targets
- Android Keystore usage: verifying cryptographic keys are bound to hardware-backed storage and not derived from predictable seeds
- APK reverse engineering: JADX and apktool decompilation to extract hardcoded secrets, internal API endpoints, and embedded credentials
- Root and tamper detection bypass: SafetyNet/Play Integrity attestation reviewed and bypass attempted using Frida hooks and Magisk modules
- WebView misconfigurations:
setJavaScriptEnabled,addJavascriptInterface, andsetAllowFileAccessreviewed for JavaScript injection and file-theft paths
Real-World Attack Scenarios We Simulate
These are findings from real engagements, not theoretical attack trees.
Credential extraction from the binary
An e-commerce app embeds its payment gateway API key in a string resource. Decompiling the APK with JADX takes under five minutes. The key is live in production and valid across all environments.
Session hijacking via unprotected token storage
A fintech app stores its OAuth access token in SharedPreferences without encryption. On a rooted device or through a compromised backup any app with storage read access extracts it and authenticates silently as that user.
Certificate pinning bypass enabling full traffic interception
A healthcare app implements certificate pinning, but the check runs in Java on the client. A Frida script hooks the validation method and returns true unconditionally. All API traffic becomes visible in Burp Suite, including PHI in JSON response bodies.
Authorization failure behind a secure-looking mobile front-end
The app enforces role separation correctly in the UI. The backend API doesn’t check. Replaying an authenticated request from a standard user account with a modified resource ID returns another user’s medical records, a direct OWASP Mobile Top 10 M3 (Insecure Authorization) finding.
For a related look at how authorization failures surface across SaaS and API-connected platforms, see our post on 7 SaaS Security Vulnerabilities We Found in Real Engagements.
How We Work
We run manual-led assessments aligned to the OWASP Mobile Top 10 and OWASP MASVS (Mobile Application Security Verification Standard). Static analysis covers the binary directly, no source code required. Dynamic testing runs on physical or emulated devices with full traffic interception via Burp Suite, and runtime instrumentation via Frida for bypass testing. For dual-platform engagements, iOS and Android are scoped and tested as independent assessments, each with its own toolchain and checklist, not a shared scope split across both platforms. Backend APIs in scope receive the same authorization and data exposure validation we apply in a standalone API penetration test.
Compliance Requirements This Engagement Supports
HIPAA
The Security Rule’s requirements for PHI in transit and at rest apply directly to mobile apps handling patient data. Our report documents every location where PHI is cached locally, transmitted unencrypted, or accessible beyond the intended authorization boundary. → HIPAA compliance consulting
PCI DSS (Req. 6.2 and 11.4)
Mobile apps that initiate, display, or transmit cardholder data fall within PCI scope. We assess the full transaction flow from the mobile client through to the payment API, including any in-app token handling and SDK integrations. → PCI DSS readiness services
SOC 2 (CC7.1)
Penetration test evidence is routinely requested by auditors evaluating threat detection and anomaly monitoring controls. Our report is structured for direct inclusion in SOC 2 audit packages.
ISO/IEC 27001
Risk treatment evidence for mobile app attack surfaces, mapped to relevant Annex A control areas. Shofiur Rahman, our ISO/IEC 27001 Information Security Associate™-certified lead, can provide findings contextualization aligned to your risk register.
GDPR
Data minimization and storage limitation obligations mapped to specific findings where PII is unnecessarily persisted on-device or transmitted to third-party SDKs without explicit user consent.
What You Receive
Every engagement delivers:
- Technical report – with CVSS-scored findings, step-by-step reproduction instructions, and tool-verified proof-of-concept for each vulnerability — not automated scan output
- Executive summary – written for non-technical leadership, board review, or direct submission to an auditor
- Developer-level remediation guidance – specific API calls, storage mechanisms, and configuration changes, not generic “encrypt sensitive data” recommendations
- OWASP Mobile Top 10 and MASVS traceability – each finding mapped to its relevant framework control reference
- Evidence artifacts – annotated screenshots, Burp Suite traffic captures, and Frida scripts demonstrating the exploited path
Free Retest Included
After your team applies fixes, we verify them. Retesting confirms each finding is closed and checks for regressions introduced during remediation. Included at no additional cost within the agreed retest window, because a closed vulnerability that was fixed incorrectly is still a vulnerability.
Frequently Asked Questions
What do I need to provide to start?
A test build (IPA for iOS, APK or AAB for Android) or a TestFlight/internal track invite, test accounts covering every user role in scope, and the base URLs of the backend APIs the app communicates with. Source code speeds up static analysis but isn’t required.
Do you test iOS and Android as separate engagements?
Yes and intentionally. Each platform has a distinct attack surface, tool environment, and test checklist. You can run them as separate engagements or combined into a single dual-platform assessment. Either way, we scope them independently. Neither platform gets a compressed scope to fit a combined price point.
What does a manual pentest find that an automated scanner misses?
Scanners reliably catch known-signature issues, outdated libraries, some storage misconfigurations, missing certificate pinning declarations. They can’t follow an authentication flow, chain a BOLA into a privilege escalation, bypass runtime protections, or manipulate business logic. The findings with the highest breach potential almost always require a human tester who understands how your app is supposed to behave.
How long does the engagement take?
Single-platform assessments typically run 7–10 business days from build receipt to final report. Dual-platform engagements run 12–15 business days. Apps with custom authentication, device binding, or advanced cryptographic flows may require additional time, we confirm the exact timeline during scoping.
Will the report satisfy our auditor or vendor security review?
Yes. The report includes an executive summary, CVSS-scored technical findings, reproduction evidence, remediation steps, and OWASP/MASVS control references. It’s structured for direct submission to auditors (SOC 2, PCI DSS, ISO 27001, HIPAA), enterprise security reviewers, and vendor due diligence packages.
Send Us Your App Build, We’ll Scope the Engagement Within 24 Hours
Share your IPA or APK, the platform(s) in scope, any relevant compliance deadline, and backend API access details. We’ll return a fixed-price quote, a clear testing timeline, and targeted scoping questions, no sales process, no retainer.
NDA available on request · Secure evidence handling · Compliance-ready reporting · Production-safe testing