Mobile Application Penetration Testing UAE | OWASP MASVS | iOS & Android

Mobile application security testing is critical for UAE organizations deploying banking apps, healthcare apps, e-commerce platforms, or government services. A single vulnerability — insecure data storage, weak authentication, API flaws — can expose customer data, enable fraud, and trigger regulatory penalties under NESA, DESC, CBUAE, and UAE PDPL.

eSHIELD delivers comprehensive mobile application penetration testing for iOS and Android apps across the UAE. Our OSCP-certified penetration testers follow the OWASP Mobile Application Security Verification Standard (MASVS) to identify vulnerabilities before attackers do.

What Is Mobile Application Penetration Testing?

Mobile application penetration testing (mobile app pentest) is a security assessment that simulates real-world attacks against iOS and Android applications to identify vulnerabilities before malicious actors exploit them.

Unlike automated security scanners, mobile app pentests involve manual testing by certified ethical hackers who:

• Reverse-engineer the mobile app binary (APK for Android, IPA for iOS)
• Analyze client-side code for hardcoded secrets, insecure storage, weak cryptography
• Test backend APIs for authentication bypass, authorization flaws, injection attacks
• Intercept and manipulate network traffic to identify data leakage
• Bypass security controls (SSL pinning, jailbreak detection, root detection)
• Test platform-specific vulnerabilities (Android Intent hijacking, iOS Keychain weaknesses)
• Assess compliance with OWASP MASVS and industry standards

Why manual testing matters: Automated tools miss business logic flaws, authorization issues, and complex attack chains. Only human testers can identify nuanced vulnerabilities like “user A can access user B’s data” or “payment amount can be manipulated client-side.”

Why Mobile App Pentesting Is Critical in 2026 (UAE Context)

1. UAE Regulatory Requirements

NESA, DESC, and CBUAE mandate security testing for mobile apps processing sensitive data:

• NESA IAS: Control 8.26 (Security testing in development) requires penetration testing before production deployment
• DESC ISR: Quarterly vulnerability assessments for Dubai government mobile apps
• CBUAE: Annual penetration testing for banking and fintech apps
• UAE PDPL: Requires “appropriate technical measures” to protect personal data — mobile app pentests demonstrate compliance

2. High-Profile Mobile App Breaches (UAE & Global)

• 2024: UAE delivery app exposed 500K user records due to insecure API endpoint
• 2023: Healthcare app leaked patient data via unencrypted local storage
• 2023: Banking app vulnerability allowed account takeover via JWT manipulation
• Global: Millions of users affected by mobile app supply chain attacks (compromised SDKs)

3. Mobile-Specific Attack Vectors

Mobile apps face unique threats compared to web applications:

• Rooted/Jailbroken devices: Bypass security controls, access protected data
• Insecure data storage: SQLite databases, shared preferences, plist files stored unencrypted
• Weak binary protections: Easy reverse engineering exposes API keys, business logic
• Platform fragmentation: Android’s 100+ device models create configuration vulnerabilities
• Third-party SDKs: Advertising, analytics, and payment SDKs introduce supply chain risk

4. Customer Trust & Brand Protection

UAE consumers expect mobile app security. A data breach can:

• Destroy brand reputation (social media amplifies breaches instantly)
• Trigger app store removal (Apple/Google remove insecure apps)
• Enable regulatory fines (UAE PDPL: up to AED 1M+ per violation)
• Result in class-action lawsuits (especially for financial/healthcare apps)

OWASP MASVS: The Mobile App Security Standard

The OWASP Mobile Application Security Verification Standard (MASVS) is the international benchmark for mobile app security. eSHIELD’s mobile app pentests are fully OWASP MASVS-compliant.

MASVS Levels:

MASVS-L1: Standard Security

Scope: Basic security controls for all mobile apps.

Requirements:

• Secure data storage (no plaintext credentials, sensitive data encrypted)
• Secure communication (TLS 1.2+, certificate validation)
• Authentication and session management
• Input validation (prevent injection attacks)
• Basic cryptography

Best for: Consumer apps, e-commerce, social media, informational apps.

Pentest cost: AED 25,000 – 40,000.

MASVS-L2: Defense-in-Depth

Scope: Enhanced security for apps handling sensitive data (payments, health records, confidential communications).

Additional requirements beyond L1:

• Binary protection (obfuscation, anti-tampering)
• Runtime integrity checks (detect jailbreak/root, code injection)
• Strong cryptography (AES-256, RSA-2048+)
• Advanced authentication (biometrics, certificate pinning)
• Secure key storage (iOS Keychain, Android Keystore)

Best for: Banking apps, fintech, healthcare, government services.

Pentest cost: AED 45,000 – 75,000.

MASVS-R: Resiliency Against Reverse Engineering

Scope: Apps requiring protection against reverse engineering and tampering (payment apps, DRM-protected content, high-value IP).

Additional requirements beyond L2:

• Advanced obfuscation (code, strings, resources)
• Anti-debugging techniques
• Tamper detection and response
• Device binding
• White-box cryptography

Best for: Banking apps with high fraud risk, payment processing, DRM content.

Pentest cost: AED 80,000+.

iOS vs. Android Security Testing: Key Differences

Mobile App Pentest Scope: What We Test

1. Client-Side Vulnerabilities

Insecure Data Storage (OWASP M9)

What we test:

• SQLite databases stored unencrypted
• Shared Preferences / plist files containing passwords, tokens, PII
• Sensitive data in application logs
• Cached data (images, web pages) containing sensitive information
• Clipboard data exposure
• Keyboard cache (auto-complete) leaking sensitive data

Real example: Healthcare app stored patient records in unencrypted SQLite database on device. Any app with storage permission could read patient names, diagnoses, medications.

Hardcoded Secrets (OWASP M10)

What we test:

• API keys, tokens hardcoded in app binary
• Database credentials in strings.xml (Android) or Info.plist (iOS)
• Encryption keys stored in code (defeats encryption purpose)
• Third-party API keys (AWS, Firebase, payment gateways)

Real example: Fintech app had production AWS access keys hardcoded. We extracted keys using jadx decompiler, accessed their S3 buckets containing customer KYC documents.

Weak Cryptography (OWASP M10)

What we test:

• Weak algorithms (MD5, SHA-1, DES, RC4)
• Static encryption keys (same key for all users)
• Custom crypto implementations (invariably broken)
• Predictable random number generation

Real example: Banking app used MD5 to hash PIN codes. We cracked PINs via rainbow table in under 1 minute.

Improper Session Handling (OWASP M3)

What we test:

• Long session timeouts (sessions persist for days)
• Tokens stored insecurely (shared preferences, not keychain)
• No session invalidation on logout
• Session tokens transmitted without TLS
• JWT signature verification bypass

Binary Protection & Reverse Engineering (OWASP M7)

What we test:

• Ease of reverse engineering (decompilation, disassembly)
• Obfuscation effectiveness (code, strings, resources)
• Debug mode enabled in production builds
• Backup flags enabled (Android allowBackup=”true” leaks app data)
• Anti-tampering controls

2. Server-Side API Testing

Authentication & Authorization Flaws (OWASP M4)

What we test:

• Authentication bypass (missing authentication on endpoints)
• Broken authorization (user A accessing user B’s data)
• Insecure Direct Object References (IDOR): manipulating IDs to access others’ records
• Horizontal privilege escalation (standard user accessing admin functions)
• API key validation bypass

Real example: Delivery app API: changing userID parameter let us view any user’s order history, delivery addresses, phone numbers.

API Injection Attacks (OWASP M4)

What we test:

• SQL injection (backend databases)
• NoSQL injection (MongoDB, Firebase)
• XML injection (SOAP APIs)
• Command injection (if API calls OS commands)
• LDAP injection

API Rate Limiting & DoS (OWASP M4)

What we test:

• Missing rate limiting (brute-force attacks on login/OTP)
• Resource exhaustion (large payload uploads crash server)
• Amplification attacks

Business Logic Flaws (OWASP M4)

What we test:

• Price manipulation (change product price client-side before payment)
• Promo code reuse/stacking exploits
• Transaction replay attacks
• Race conditions (double-spending, duplicate claims)

Real example: E-commerce app: changing “price” parameter in payment API from AED 1,000 to AED 1 was accepted. Server trusted client-side price.

3. Network Communication Security

Insecure Communication (OWASP M5)

What we test:

• Cleartext transmission (HTTP instead of HTTPS)
• Weak TLS versions (TLS 1.0, TLS 1.1)
• Weak cipher suites (RC4, 3DES)
• Missing certificate validation (accepts self-signed certs)
• SSL certificate pinning bypass

Man-in-the-Middle (MitM) Attacks

What we test:

• Intercept network traffic via proxy (Burp Suite, OWASP ZAP)
• Bypass certificate pinning using Frida, SSL Kill Switch
• Modify requests/responses in transit
• Capture sensitive data (passwords, tokens, PII) transmitted unencrypted

4. Platform-Specific Vulnerabilities

Android-Specific

• Exported components: Activities, Services, Broadcast Receivers exposed to other apps
• Intent hijacking: Malicious apps intercept intents meant for your app
• Content Provider leakage: Sensitive data exposed via content providers
• WebView vulnerabilities: JavaScript injection, file access via WebView
• Tapjacking: Overlay attacks trick users into clicking hidden buttons
• Backup flag: allowBackup=”true” allows ADB backup extraction

iOS-Specific

• URL Scheme hijacking: Malicious apps register same URL scheme
• Keychain access control: Weak access control allows other apps to read your keychain items
• Pasteboard leakage: Sensitive data left on clipboard accessible to other apps
• Insecure biometric implementation: Weak Face ID/Touch ID integration
• App Transport Security (ATS) bypass: Disabling ATS allows insecure connections

5. Third-Party SDK Risks

What we test:

• Outdated SDKs with known vulnerabilities (Firebase, analytics SDKs)
• Excessive SDK permissions (tracking, location access)
• SDK data exfiltration (sending device data to third-party servers)
• Advertising SDK security (malvertising injection points)

Mobile App Pentest Process: 6 Phases

Phase 1: Scoping & Kickoff (1-2 days)

Activities:

• Define scope (iOS, Android, or both)
• Identify app features to test (login, payments, data access, file upload, etc.)
• Determine OWASP MASVS level (L1, L2, or R)
• Obtain app binaries (IPA, APK) and test credentials
• Set up test environment (jailbroken iOS device, rooted Android device/emulator)

Deliverable: Pentest scope document, rules of engagement, NDA execution.

Phase 2: Reconnaissance & Information Gathering (1-2 days)

Activities:

• Static analysis: decompile APK/IPA, analyze code structure
• Identify API endpoints (backend URLs, REST/GraphQL APIs)
• Map attack surface (user roles, features, data flows)
• Enumerate third-party SDKs and libraries
• Check for known vulnerabilities in dependencies

Tools: jadx, Hopper, Ghidra, MobSF (Mobile Security Framework), apktool, class-dump.

Phase 3: Dynamic Testing (5-8 days)

Activities:

• Install app on jailbroken/rooted device
• Configure intercepting proxy (Burp Suite)
• Bypass SSL pinning (Frida, SSL Kill Switch)
• Test authentication & authorization
• Test input validation (injection attacks)
• Test session management
• Test business logic flaws
• Test platform-specific vulnerabilities (exported components, URL schemes)
• Attempt privilege escalation

Tools: Burp Suite, OWASP ZAP, Frida, Objection, Drozer, MobSF, Proxyman.

Phase 4: Static Code Analysis (2-3 days)

Activities:

• Decompile app binary to source-level code
• Search for hardcoded secrets (API keys, passwords)
• Analyze cryptographic implementations
• Review data storage mechanisms
• Identify insecure coding practices (eval, exec, SQL concatenation)
• Check for debug code left in production

Tools: MobSF, Semgrep, grep, manual code review.

Phase 5: Exploitation & Impact Validation (1-2 days)

Activities:

• Exploit identified vulnerabilities to demonstrate real-world risk
• Chain vulnerabilities for maximum impact
• Document proof-of-concept exploits
• Capture screenshots/videos of successful exploits
• Quantify business impact (data exfiltration, financial loss, compliance violation)

Phase 6: Reporting & Remediation Guidance (2-3 days)

Activities:

• Write comprehensive pentest report
• Rate vulnerabilities (Critical, High, Medium, Low, Informational)
• Provide detailed remediation guidance (code fixes, configuration changes)
• Deliver report to client
• Present findings walkthrough (1-hour session with dev team)
• Answer remediation questions

Deliverable: 40-80 page pentest report with executive summary, technical findings, proof-of-concepts, remediation guidance.

Total timeline: 2-4 weeks from kickoff to report delivery (simple app: 2 weeks, complex app: 3-4 weeks).

Mobile App Pentest Pricing UAE (2026)

What’s included:

• ✅ iOS and/or Android testing (specify scope)
• ✅ Client-side + server-side API testing
• ✅ OWASP MASVS-compliant testing
• ✅ OWASP Mobile Top 10 coverage
• ✅ Comprehensive report (40-80 pages)
• ✅ Executive summary + technical findings
• ✅ Proof-of-concept exploits
• ✅ Remediation guidance (code-level fixes)
• ✅ Findings walkthrough session (1 hour)
• ✅ 30 days post-report Q&A support

Add-ons:

• +AED 10K: Retest after remediation (recommended to verify fixes)
• +AED 15K: Source code review (white-box testing, deeper analysis)
• +AED 8K: Secure code training for developers (4-hour workshop)

OWASP Mobile Top 10 (2024): What We Test For

M1: Improper Credential Usage

Hardcoded passwords, API keys, tokens in code or configuration files. Easy to extract via reverse engineering.

Impact: Complete system compromise if production keys leaked.

Real example: AWS keys hardcoded → full S3 bucket access.

M2: Inadequate Supply Chain Security

Vulnerable third-party libraries and SDKs (Log4j, outdated Firebase, advertising SDKs with known exploits).

Impact: Remote code execution, data exfiltration.

M3: Insecure Authentication/Authorization

Weak authentication (no rate limiting on OTP, predictable tokens), broken authorization (IDOR, privilege escalation).

Impact: Account takeover, unauthorized data access.

M4: Insufficient Input/Output Validation

SQL injection, XSS, command injection, path traversal due to unvalidated user input.

Impact: Database breach, remote code execution.

M5: Insecure Communication

Cleartext transmission, weak TLS, missing certificate pinning → Man-in-the-Middle attacks.

Impact: Credential theft, session hijacking, data leakage.

M6: Inadequate Privacy Controls

Excessive data collection, lack of consent, no data minimization, PII leakage to third parties.

Impact: UAE PDPL violations, GDPR fines (if EU data), user trust loss.

M7: Insufficient Binary Protections

No obfuscation, debug mode enabled, easy reverse engineering exposes business logic and secrets.

Impact: Intellectual property theft, secret extraction, piracy.

M8: Security Misconfiguration

Insecure default settings, enabled debug logs in production, misconfigured permissions.

Impact: Information disclosure, unauthorized access.

M9: Insecure Data Storage

Plaintext storage of passwords, tokens, PII in databases, logs, backups accessible to other apps or via device theft.

Impact: Data breach via physical device access or malicious apps.

M10: Insufficient Cryptography

Weak algorithms (MD5, DES), static keys, custom crypto, predictable random numbers.

Impact: Data decryption, authentication bypass.

UAE Compliance Requirements for Mobile Apps

NESA IAS (National Electronic Security Authority)

Applicability: Federal entities, critical infrastructure (banking, healthcare, energy) deploying mobile apps.

Requirements:

• Control 8.26: Security testing before deployment (pentesting required)
• Control 8.27: Secure development lifecycle
• Annual penetration testing for production mobile apps
• Remediate critical/high findings before deployment

DESC ISR v3 (Dubai Electronic Security Centre)

Applicability: Dubai government entities, semi-government, key suppliers with mobile apps.

Requirements:

• Quarterly vulnerability assessments
• Annual penetration testing
• Mobile app security must meet ISR v3 secure development controls

CBUAE (Central Bank of UAE)

Applicability: Banking and fintech apps.

Requirements:

• Annual penetration testing (minimum)
• Pre-deployment security assessment for new app versions
• Incident reporting (72-hour notification for breaches)
• Strong authentication (2FA, biometrics)
• Transaction security (encryption, signing)

UAE PDPL (Personal Data Protection Law)

Applicability: All UAE mobile apps collecting personal data.

Requirements:

• “Appropriate technical and organizational measures” to protect personal data
• Mobile app pentest demonstrates technical measures
• Data minimization (collect only necessary data)
• Breach notification (within 72 hours)
• Penalties: Up to AED 1M+ per violation

Mobile App Security Best Practices (Developer Guidance)

1. Secure Data Storage

• Use platform-provided secure storage: iOS Keychain, Android Keystore (not shared preferences/plist)
• Encrypt sensitive data at rest: AES-256 with secure key management
• Never log sensitive data: No passwords, tokens, PII in logs
• Secure backups: Android: set allowBackup=”false” or encrypt backup data

2. Secure Network Communication

• Always use HTTPS: TLS 1.2 minimum, TLS 1.3 preferred
• Implement certificate pinning: Prevent MitM attacks
• Validate SSL certificates: Don’t accept self-signed certs in production
• Use secure WebSocket (wss://): If using WebSockets

3. Authentication & Authorization

• Server-side session validation: Never trust client-side tokens without server validation
• Short token lifetimes: Access tokens: 15-60 minutes, refresh tokens: 7-30 days
• Implement 2FA/MFA: For sensitive operations (payments, profile changes)
• Rate limiting: Prevent brute-force on login/OTP
• Validate authorization on every API call: Check user permissions server-side

4. Input Validation

• Validate all user inputs: Client-side AND server-side
• Use parameterized queries: Prevent SQL injection
• Sanitize outputs: Prevent XSS in WebViews
• Limit file upload types and sizes: Prevent malicious file uploads

5. Binary Protection

• Obfuscate code: ProGuard (Android), Swift obfuscators
• Strip debug symbols: Don’t ship debug builds to production
• Implement root/jailbreak detection: Warn users or restrict functionality
• Add tamper detection: Detect if app has been modified

6. Third-Party SDK Management

• Minimize SDK usage: Each SDK = attack surface increase
• Vet SDKs before integration: Check security track record, permissions
• Keep SDKs updated: Monitor for security patches
• Review SDK permissions: Principle of least privilege

Frequently Asked Questions

1. How much does mobile app penetration testing cost in UAE?

Pricing ranges: Simple app (5-10 screens, single platform): AED 25K-35K. Medium app (10-20 screens): AED 40K-60K. Complex app (both platforms, 20+ screens): AED 65K-90K. Banking/fintech: AED 100K-150K. Timeline: 2-4 weeks.

2. What’s the difference between iOS and Android app pentesting?

Both test client-side, server-side, and network security. Differences: iOS uses Keychain (more secure by default), harder to reverse-engineer. Android uses Shared Preferences (often misconfigured), easier to decompile. Platform-specific vulns: iOS (URL scheme hijacking), Android (Intent hijacking, exported components). Both platforms tested thoroughly.

3. Do I need OWASP MASVS L1, L2, or R?

L1: Standard security for consumer apps (e-commerce, social, informational). L2: Defense-in-depth for sensitive data apps (banking, healthcare, government). R: Resiliency for high-risk apps (banking with fraud threats, DRM content). Most UAE apps need L1 (consumer) or L2 (financial/healthcare).

4. How long does mobile app penetration testing take?

Typical timeline: 2-4 weeks from kickoff to report delivery. Simple app: 2 weeks. Medium app: 3 weeks. Complex app or both platforms: 4 weeks. Banking/fintech: 5-6 weeks. Retest after remediation: 1 week.

5. What’s included in the pentest report?

Comprehensive 40-80 page report including: Executive summary, OWASP Mobile Top 10 coverage, detailed findings (Critical/High/Medium/Low), proof-of-concept exploits, screenshots, remediation guidance (code-level fixes), OWASP MASVS compliance summary. Plus: 1-hour findings walkthrough with dev team.

6. Is mobile app pentesting required for NESA/DESC compliance in UAE?

Yes. NESA Control 8.26 requires security testing before deployment. DESC ISR requires annual penetration testing. CBUAE requires annual testing for banking apps. Mobile app pentest satisfies these requirements.

7. Can automated tools replace manual mobile app pentesting?

No. Automated tools (MobSF, Veracode) find basic issues (insecure storage, weak crypto) but miss: Business logic flaws, authorization issues (IDOR), complex attack chains, platform-specific vulns. Manual testing by OSCP-certified pentesters finds 60-80% more critical vulnerabilities than automated scans.

8. Do you test both iOS and Android versions?

Yes. We test both platforms (scoped separately or together). Most clients test both since vulnerabilities differ by platform. Testing both ensures comprehensive coverage. Pricing: add 40-50% for second platform vs. testing single platform.

9. What happens if you find a critical vulnerability during the pentest?

We immediately notify you (within 24 hours) of Critical findings that pose imminent risk (active exploit, data exposure). You can pause pentest to remediate if needed. Formal report includes all findings at completion. Critical = immediate risk (e.g., unauthenticated access to all user data).

10. Do I need to provide source code for the pentest?

Not required for black-box testing (most common). We work with compiled binaries (APK, IPA). Optional: Provide source code for white-box testing — allows deeper analysis, finds more issues, costs +AED 15K. Black-box simulates real attacker (no source code), white-box simulates malicious insider.

11. How often should I pentest my mobile app?

Minimum: Annually (NESA/DESC requirement). Recommended: Before major releases (new features, payment integration, API changes), after security incident, when adding new third-party SDKs. Continuous security: quarterly pentests for high-risk apps (banking, healthcare).

12. What’s the difference between VAPT and mobile app pentesting?

VAPT (Vulnerability Assessment & Penetration Testing) is broader: includes network, web app, infrastructure. Mobile app pentest is specialized: focuses only on mobile app (client-side + backend APIs). Mobile app pentest is deeper on mobile-specific issues (reverse engineering, binary protection, platform vulns). Order both for complete coverage.