Mobile Application Penetration Testing
Protect your Android and iOS apps with evidence-led testing of mobile clients, privacy controls and supporting APIs.
Book a free no obligation informal chat
Protect your app, its users and the services behind it
Assess the security of your Android and iOS applications and their supporting APIs with a risk-led penetration test. Oxford Systems examines how your app handles sensitive information, enforces access controls and responds to realistic misuse, giving your teams clear evidence and practical priorities for improvement.
Testing is shaped around your threat model, business consequences, data sensitivity and exposed user journeys. The primary target is a signed release or release-candidate build in a production-equivalent configuration.
An agreed scope. A controlled assessment.
Before testing begins, we agree written authority, rules of engagement, app identifiers, API endpoints, environments, testing windows and escalation procedures. We confirm ownership or permission for third-party systems and establish emergency stop conditions.
We map architecture, data flows, roles and high-value journeys, then combine static analysis, on-device testing and runtime analysis with manual validation of potential findings. Testing goes only far enough to establish impact within the agreed boundaries.
Black-box, grey-box or white-box access can be agreed during scoping. Supplementary instrumented builds can help analysis, but results are reconciled against the protected release build.
What the assessment can cover
- Storage and cryptography: files, databases, caches, backups, logs, keys, encryption and residual data.
- Authentication and authorisation: registration, recovery, MFA, passkeys, biometrics, sessions, tokens, roles and tenant separation.
- Network communications: TLS, certificate validation, cleartext restrictions, sensitive-data leakage and pinning where applicable.
- Platform interaction: deep links, exported components, permissions, WebViews, inter-app communication, notifications and extensions.
- Code and build: signing, release configuration, embedded secrets, dependencies, SDKs and provenance where in scope.
- Resilience: threat-led assessment of tamper resistance, runtime integrity and compromised-device behaviour.
The coverage plan records the controls selected, test depth, exclusions and dependencies. The absence of a resilience control or certificate pinning is not automatically treated as a vulnerability.
Understand where personal data goes
We examine permissions, identifiers, trackers, analytics and third-party SDK disclosures against the app’s stated purposes and privacy choices. Testing can include high-privacy defaults, consent and opt-out behaviour, retention, logout, deletion and information exposed through screenshots, notifications or the clipboard.
Test data and captured evidence are minimised, protected and retained only as agreed. Secrets and unrelated personal data are redacted from reporting.
Test the API and the business journey
A secure mobile interface also depends on the services behind it. Where included in scope, we test supporting APIs for object-, function- and property-level authorisation, input validation, injection, security misconfiguration and sensitive-data exposure.
We assess application-specific abuse cases such as workflow manipulation, replay, entitlement abuse and transaction integrity. Findings distinguish mobile-client weaknesses from server-side root causes, with affected versions and endpoints recorded precisely.
Evidence your engineers can act on
- An agreed scope, rules of engagement and coverage plan.
- Immediate notification of critical issues under the agreed escalation plan.
- A quality-assured report with an executive summary, reproducible findings, redacted evidence and practical remediation advice.
- A coverage matrix stating Pass, Fail, Not Applicable or Not Tested, with reasons for gaps.
- Technical severity using CVSS 4.0 scores and vectors, alongside a separate assessment of business priority.
- A technical debrief and an executive readout where commissioned.
Retesting validates fixes against an identified replacement app build and backend version. The retest report records resolved, partially resolved and not-retested findings, with new evidence and residual risk.
A recognised mobile testing baseline
Our methodology uses the OWASP Mobile Application Security Verification Standard (MASVS) and Mobile Application Security Testing Guide (MASTG), with findings mapped where practicable to relevant controls, weaknesses and test identifiers. Supporting API assessment draws on OWASP API guidance and ASVS. Applicable standards are revalidated at the start of each engagement.
Relevant regulatory and contractual obligations are considered during scoping. A penetration test supports assurance; it does not, by itself, demonstrate legal compliance or guarantee that an application is free from vulnerabilities.
Preparing for your assessment
We agree the Android and iOS builds, supported device and OS versions, backend environments, test accounts and roles. Architecture information, API specifications, source code or build records may be requested according to the access model.
Standard testing excludes denial-of-service, destructive activity, social engineering, attacks against real users and third-party infrastructure without permission. Assessments are time-boxed and prioritised by risk; inaccessible or untested areas are made explicit.
Discuss your mobile application assessment
Tell us about your Android or iOS app, the APIs it uses, your release plans and the user journeys you need to protect. We will agree the scope, build requirements, testing permissions and reporting arrangements with you.
Request a mobile application testing quote