Application Security

Mobile Application Penetration Testing (iOS and Android)

A mobile application penetration test covers iOS, Android and the backend API; every assessment is led by senior testers.

What is tested and why it matters

From binary analysis to backend interaction, across both platforms.

Mobile applications operate in an environment the organisation does not control. The device is in the hands of the user, and the application binary can be extracted, reversed, and instrumented by an attacker. Sensitive data stored locally, unprotected API calls, missing certificate pinning, and weak inter-process communication channels are common weaknesses that automated app store scans do not detect. A compromised mobile application can expose user credentials, payment data, health records, or internal system access depending on the application purpose. Manual security testing by experienced ethical hackers identifies weaknesses in how the application handles data at rest, data in transit, and runtime manipulation on both Android and iOS platforms.

Standards OWASP MSTG, MASVS, ASVS

Attack surface Secure storage, IPC, certificate pinning, runtime manipulation, backend API calls

Approach Reverse engineering, static analysis, and dynamic testing on controlled devices

Who needs this assessment

Organisations that depend on mobile channels for sensitive transactions.

This assessment is designed for organisations where a mobile application is a primary channel for customer interaction, employee access, or partner integration involving sensitive data.

Banking and fintech providers with customer-facing mobile applications

Healthcare organisations processing patient data through mobile channels

Retail, logistics, and e-commerce platforms with mobile ordering or delivery applications

Organisations with internal employee applications handling sensitive operational data

Development teams preparing a mobile release that requires independent security validation before launch

Healthcare organisations and government agencies providing citizen-facing mobile applications subject to regulatory security requirements

Where these assessments are relevant

Financial services: customer portals, payment processing, and cloud-hosted transaction infrastructure.
SaaS and technology: application validation before production deployment or enterprise procurement.
Healthcare: digital systems handling patient data, clinical records, and connected medical devices.
Retail and e-commerce: web applications processing transactions, customer accounts, and payment data.

What the assessment produces

The insight and evidence delivered at the conclusion of the assessment.

Every assessment concludes with a structured report covering technical findings, severity ratings, evidence, and remediation guidance. Reports are delivered through the Pentrox Portal and are available for download at any time.

A prioritised list of confirmed vulnerabilities across the mobile application, its local data storage, and its backend interactions
Validation of platform-specific security controls (Keychain, Keystore, certificate pinning, root and jailbreak detection)
Identification of hardcoded secrets, insecure storage patterns, and unprotected inter-process communication channels
A report structured for both development teams and executive leadership, delivered within five business days after completion of testing
Portal access with real-time findings, retest workflow, and report downloads for the lifetime of the client account

How an assessment runs

Scope and Intake
Planning
Assessment
Reporting
Findings & Retest

Retesting of remediated findings is included as standard with every assessment.

Assessment methodology

Five phases from reverse engineering through verified remediation.

Each phase builds on the previous one. Binary analysis informs dynamic testing, runtime instrumentation confirms static findings, and quality review ensures every reported vulnerability is reproducible.

Application reconnaissance

The application binary is obtained and reviewed for permissions, exported components, embedded libraries, and declared network endpoints.

OWASP MSTG (Platform Interaction, Network Communication), OWASP MASVS L1/L2

Reverse engineering and static analysis

The binary is decompiled and reviewed for hardcoded secrets, insecure cryptography, and unsafe code constructs. Third-party library CVEs are identified.

OWASP MSTG (Code Quality, Cryptography), CWE Top 25, OWASP MASVS V3 (Cryptography)

Dynamic testing and runtime manipulation

Frida and Objection test certificate pinning, anti-tampering controls, and root/jailbreak detection. Traffic is intercepted with Burp Suite Professional.

OWASP MSTG (Resilience Requirements, Network Communication), OWASP MASVS R1-R8

Backend and API interaction testing

API calls from the mobile application are tested for authentication weaknesses, authorisation bypass, and data exposure. Sensitive data flows between the application and backend are traced.

OWASP API Security Top 10, OWASP ASVS (Authentication, Session Management)

Reporting, quality review, and retesting

Findings are documented with platform indication (Android, iOS, or both), severity rating, and remediation guidance. Every report undergoes internal quality review before delivery.

OWASP Risk Rating Methodology (severity rating), OWASP MASVS (verification mapping)

Scope and deliverables

What is included, what is excluded, and what is delivered.

The statement of work defines the exact platforms, application versions, and testing approach before the assessment begins. The lists below reflect the standard scope for a mobile application security assessment.

In scope

iOS and Android application penetration testing
Secure storage and encryption validation (Keychain, Keystore, shared preferences)
Certificate pinning, TLS, and network configuration review
Runtime manipulation, instrumentation, and debugger detection testing
Inter-process communication and exported component analysis
API interaction and backend dependency testing
Third-party library security and dependency hygiene assessment
Reverse engineering of the application binary

Out of scope

Testing of backend infrastructure beyond the API endpoints called by the application
Denial-of-service testing unless explicitly agreed in the statement of work
Testing on devices not provided or agreed in the scope definition
App store review processes or submission compliance

What you receive

Executive summary Severity distribution, risk overview, and remediation priorities written for leadership.
Detailed findings Each vulnerability documented with evidence, platform indication (Android, iOS, or both), OWASP risk rating, and remediation guidance.
Technical conclusion Findings linked to the overall mobile threat surface with structural recommendations.
Scope and strategy description Goals, test approach, and scope boundaries for audit traceability.
Portal access Real-time findings, report downloads, retest workflow, and team management through a dedicated platform.
Findings meeting A scheduled session to align on risks, priorities, and the remediation approach.
Retest report Verification results after remediation, documenting each finding with its updated status.

Pentrox Portal report library showing the four report types available for download

See what a Pentrox report looks like before you decide

Mobile application security testing

What static and dynamic testing reveal in iOS and Android apps.

API security testing beyond the OWASP Top 10

The API behind the app: authorisation, rate limits and excessive data exposure.

What to expect during your first penetration test

The five stages from scoping to retest and what each asks of your team.

When independent assessment is the right step

An independent assessment is required ahead of an audit, a product launch, or a funding round, and the organisation needs documented evidence from a third party.

Digital platforms handle revenue, customer data, or service delivery, and the security of those platforms has not been validated by an external party.

Existing security controls have been implemented but have not been tested from an attacker perspective to confirm they work as intended.

Request a scoping call

Timeline

Illustrative durations to support planning. Confirmed in the statement of work.

The duration of a mobile application security assessment depends on the number of platforms, the complexity of the application, and the depth of backend API interaction. The calibration bands below are indicative. Exact duration is confirmed in the statement of work.

Small scope 3 to 4 testing days Single platform (Android or iOS), limited backend interaction, and straightforward authentication

Core scope 4 to 7 testing days Both platforms, moderate backend API interaction, and platform-specific security controls to validate

Complex scope 7+ testing days Both platforms with extensive backend integration, advanced anti-tampering controls, and multiple user roles

Report delivery 5 business days Initial report and management report are delivered shortly after testing is completed.

Retest Included as standard Retesting within 90 days after report delivery is included at no additional cost.

What determines duration

Number of platforms under test (Android, iOS, or both)
Application complexity: native, hybrid, or API-backed architecture
Depth of backend API interaction and number of endpoints
Whether source code or build artifacts are provided (white box vs black box)
Anti-tampering, obfuscation, and root/jailbreak detection maturity

Actual duration is confirmed during scoping and depends on test approach and device requirements. A statement of work confirms the exact scope and timeline before the assessment begins. The final report is delivered within five business days after completion of testing.

Why Pentrox

The operational standards behind every mobile application assessment.

These operational standards apply to every mobile application assessment Pentrox delivers, regardless of platform or testing approach.

Both platforms, one assessment

Android and iOS tested by the same team in a single assessment cycle.

Both Android and iOS implementations are tested in the same assessment. Platform-specific weaknesses are identified on each build. A single report covers both platforms.

Manual reverse engineering

Binary analysis that goes beyond automated scanning.

Application binaries are decompiled and reviewed by experienced ethical hackers. Hardcoded secrets, insecure cryptography, and unsafe code constructs are identified through manual analysis.

Runtime and anti-tampering validation

Certificate pinning, root detection, and code obfuscation tested under real conditions.

Runtime instrumentation using Frida and Objection tests whether anti-tampering controls withstand a motivated attacker with physical access to the device.

Direct access to the tester

No account managers between the client and the security expert.

Critical or blocking findings are escalated immediately through the channel agreed at kickoff. Remediation can begin well before the final report is delivered.

Portal-delivered results

Findings visible in real time through the Pentrox Portal.

The Pentrox Portal provides remediation tracking, retest requests, report downloads, and team access management. Two-factor authentication and role-based access control are enforced on every account.

Frequently asked questions

Practical answers for security teams and procurement officers.

Is the methodology aligned with OWASP MASVS?

The assessment follows the OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Security Testing Guide (MSTG). Findings are mapped to MASVS requirements. NIAP Protection Profiles are referenced where applicable to the platform and deployment context.

Are both Android and iOS platforms tested?

Both platforms are tested within the same assessment. Each platform is evaluated for platform-specific weaknesses (Keychain vs Keystore, ATS vs cleartext traffic, iOS Sandbox vs Android permissions). A single report covers both builds with platform-specific findings clearly indicated.

Is retesting included?

Retesting of remediated findings is included as standard with every assessment. There are no additional charges. The client flags remediated findings through the Pentrox Portal and submits a retest request. Results are published through the Portal once the verification is complete.

What devices are used for testing?

Testing is performed on controlled devices with instrumentation capabilities. Specific device models and OS versions are agreed in the statement of work. Where the client requires testing on a specific device or configuration, this is arranged during the scoping phase.

Does the assessment cover the backend API?

API calls originating from the mobile application are tested for authentication, authorisation, and data exposure weaknesses. The scope covers the API endpoints that the mobile application interacts with. Full backend infrastructure testing beyond these endpoints is covered under the Web and API Penetration Testing assessment.

What clearances do the testers hold?

All Pentrox employees undergo PES (Personnel Screening) background checks upon commencement of employment. Team members hold one or more industry-standard certifications such as OSCP, OSCE, OSWE, eWPTX, eMAPT, CPTS, CWES and BSCP. Every assessment is performed or supervised by senior penetration testers.

How is assessment data handled and who has access to findings?

Findings, reports, and project data are stored in the Pentrox Portal, hosted on a dedicated VPS in a datacenter in the European Union. Access is controlled through mandatory two-factor authentication and role-based permissions. The client manages team membership. Data remains accessible for the lifetime of the client account and is removed only on explicit request.

What happens when a critical vulnerability is found during testing?

Critical or blocking vulnerabilities are communicated immediately through the channel agreed at kickoff. Findings are published in the Pentrox Portal as they are confirmed, so remediation can begin before the final report is delivered. The escalation path is documented in the statement of work.