Mobile application penetration testing
Mobile app penetration testing
Your iOS or Android app, device controls and APIs tested as one connected attack surface. Our penetration testers work with A.R.T. to uncover weaknesses, validate how they combine and show what an adversary could reach.
A penetration tester replies within one working hour to ask the questions needed to scope your test.
Overview
What is mobile application penetration testing?
We assess the mobile client, its use of the operating system, information held on the device, network communication and supporting APIs. iOS and Android are treated as separate builds and attack surfaces, even when they share services. The result shows which controls fail when the official client cannot be trusted.
This is for you if…
Sensitive functions sit in the app
It handles personal records, payments, device features or sensitive actions that need independent assurance.
Someone has asked for a test
A client, an insurer or a regulator wants evidence that an independent tester has checked the app.
A release is coming
A new app, or a large change to one, goes live soon and you want it tested first.
New to the term? Penetration testing, defined in our glossary
Why you need it
Why does your mobile app need a penetration test?
A mobile client runs on a device outside the organisation's control. Its package can be inspected, local information recovered and requests altered or recreated. Security must be enforced across the application, operating system, network communication and supporting services rather than relying on the official client.
Application package
Embedded secrets, endpoints, debug code and client-side logic in each iOS or Android build included in scope.
Device and operating system
Storage, permissions, logs, screenshots, links and platform controls that affect information handled on the device.
Network communication
Transport security and what happens when authorised requests are observed, changed or replayed outside the intended client.
APIs and services
Authentication, authorisation, input validation and business rules that the server must enforce independently.
Motive
Where does mobile application risk sit?
The official application is only one way to reach the service behind it. An adversary can inspect client logic, alter local state and recreate API calls without following the intended screens. The assessment establishes which decisions the server makes independently and which still trust the client.
We agree the sensitive information, roles and functions that matter most, then prioritise testing around those outcomes. Each finding explains the affected platform, client or API control and the practical impact of the weakness.
Information on the device
Tokens, files, databases and screen content that should stay protected outside a session.
Identity and sessions
Authentication, biometrics and tokens that must remain bound to the right user.
Platform capabilities
Permissions, links and exported components that shape how the app uses the platform.
Server-side enforcement
APIs and services that must reject altered requests regardless of which client sends them.
Reach
What happens when the official client cannot be trusted?
Client analysis may reveal an undocumented interface or an assumption made by the server. We recreate authorised requests outside the official app, alter them and test whether the API enforces the same identity, role and workflow boundaries. Material impact is validated safely within the agreed scope and rules of engagement.
Entry
Analyse the client
The authorised build reveals an interface used by a sensitive function.
Yields an endpoint to investigate
Step
Recreate the request
A valid request is sent outside the official client within the agreed environment.
Yields the API's independent response
Step
Alter the context
A role, object or workflow value is changed to test server-side enforcement.
Yields evidence of a missing control
Impact
Validate the impact
The tester confirms the data or action exposed within the agreed safeguards.
Yields a verified finding
In practice
Static and dynamic analysis can include reverse engineering, local storage, permissions, deep links, transport security, session handling and integrity controls. Rooted or jailbroken devices, binary modification and certificate pinning bypass are used only where the platform, protections, objectives and rules of engagement make them relevant.
Pinning bypass on a controlled device is a way to inspect authorised traffic, not a finding by itself. Findings focus on weaknesses in the trust, transport or server-side control model and are prioritised by practical impact.
Methodology
How Adversify tests your mobile app
Before testing, we agree platforms, builds, roles, APIs and safeguards. We analyse each client, inspect connected services with manual work and A.R.T., validate material impact and report one assessment that gives your teams a clear, shared view of the result.
- The build
- Storage
- Sign-in
- Traffic
- APIs
Engagement design
We agree each platform and build, its distribution method, the environments and APIs it uses, supplied user roles, sensitive functions, safeguards and exclusions. The rules of engagement record access, devices, contacts and escalation arrangements.
- Scope
- Rules of engagement
- Test accounts
Analyse the attack surface
We unpack the build, map client logic, platform interaction, local storage, traffic, roles and services, and compare how each platform uses the shared back end. This identifies trust boundaries and the areas that warrant deeper investigation.
- Static analysis
- Traffic mapping
- User roles
Investigate and validate
Manual testing and A.R.T. examine application behaviour, storage, traffic, identity and APIs. The penetration tester selects relevant platform techniques, approves sensitive actions and validates whether altered requests or combined weaknesses create practical impact.
- Manual testing
- A.R.T.-assisted
- Safe validation
Reporting and evaluation
One Adversify report connects each finding to the affected build, device behaviour, role or API. It includes a plain summary, validated evidence, reproduction steps and prioritised remediation, followed by a debrief with the people who performed the work.
- Executive summary
- Evidence
- Debrief
Support after the report
While your developers make their changes, the testers stay on hand to answer questions about a finding, so each one is worked through with the people who found the problem.
- Tester support
- Developer questions
- Remediation advice
AI integration
Where does AI take part in this test?
A.R.T. works alongside the penetration tester throughout the assessment. Specialised agents correlate client behaviour with API activity, investigate roles, inputs and workflows in parallel and share useful context across both. The tester oversees the scope, approves sensitive actions and validates every result before it enters one Adversify report.
How the A.R.T. agents are organised, in three tiers:
- Tier 1: the lead tester, which coordinates the domain testers.
- Tier 2: three security domain testers, for application testing, authorisation review and input handling.
- Tier 3: a group of testers under each domain tester.
Work passes down the tiers and findings pass back up. An Adversify pentester oversees all three tiers and the work, approving sensitive actions and verifying findings.
Lead tester
A.R.T. does The lead agent plans focused investigations from how your app and its exposed interfaces work, within the agreed scope.
Adversify pentester does The pentester agrees the scope, the app builds, access and exclusions with you and stays involved throughout.
Domain testers
A.R.T. does Each domain tester takes one security concern in the app, such as data stored on the device or the APIs behind it.
Adversify pentester does The pentester approves or denies any sensitive action before it is carried out.
Testers
A.R.T. does Testers examine the app's relevant functions within the agreed scope and connect related weaknesses into attack paths.
Adversify pentester does The pentester verifies each finding and its impact before it goes into your Adversify report.
Coverage
What does a mobile app penetration test cover?
Depending on the agreed scope, testing may include static and dynamic analysis, local storage, platform controls, traffic, identity, sessions and supporting APIs. Coverage is confirmed separately for each platform and build because shared services do not make the client code or platform behaviour identical.
Reverse engineering the build
The package unpacked and read for hard-coded secrets, hidden endpoints and debug settings, then altered to see whether it resists tampering.
Data stored on the device
Files, databases, the keychain and logs, checked for anything that should not outlive a session.
Sign in, sessions and encryption
Passwords, biometrics, tokens and sign out, tested for every way around them, and the encryption guarding what the app keeps and sends.
Network communication
Transport security and certificate pinning, and what can be read or changed in transit.
Platform configuration
Permissions, manifests, deep links, URL schemes, exported components and integrity controls where relevant to the platform and scope.
The APIs behind the app
In-scope endpoints the app calls, tested with its own session, another user's and none, and for injection and input validation flaws.
OWASP MASVS and MASTG inform testing. Formal verification against every MASVS control is included only where it is explicitly agreed in scope.
What you get
What you get from a mobile app penetration test
You receive one Adversify report that identifies the affected platform, build, device behaviour, role and API for each validated finding. It combines a plain-language assessment, reproducible evidence and practical remediation. Priorities reflect what each weakness enables, with a debrief for engineering and leaders.
You receive
The penetration test report
A summary your leadership can act on, and findings your developers can work from.
Evidence for every finding
Screenshots, requests and steps to reproduce, with the layer each was found at.
Remediation guidance
What to change, in priority order, written for the developers of the platform it affects.
A debrief with the testers
A call with the people who did the work, for engineering and leadership together.
What changes
- Scope can cover the app, the phone and the back end behind it
- Findings are proved by following them to what they reach
- You know what to change first and where the next test starts
Questions
Mobile app penetration testing questions
These answers explain how iOS and Android are scoped, when APIs are included, which builds and accounts are needed, how platform protections are handled and where A.R.T. contributes. A tester agrees the exact boundary with you before testing work begins.
Not answered here? Ask it on the scoping call
Do you test the iOS app, the Android app or both?
Either or both. Each platform and build is identified separately because its code, operating-system interaction and API use may differ. Shared back-end services are scoped according to the functions and interfaces used by each client rather than assumed to need testing only once.
Are the supporting APIs included?
They can be. The scoping call identifies the APIs and environments used by each build and agrees the depth of direct testing. We recreate requests outside the official client to establish whether server-side authentication, authorisation and input validation hold independently.
What access do you need from us?
A build for each platform, or access through the store, test accounts for each kind of user and a named contact during testing. Where the back end is in scope, we also agree which environment we may test against.
How do you assess pinning and tamper controls?
We select techniques according to the platform, protections and objectives. Bypassing pinning may allow authorised traffic inspection on a controlled device, but it is not automatically a vulnerability. Any reported finding must show a weakness in the trust or control model.
How is A.R.T. used during the assessment?
A.R.T. works alongside the penetration tester, correlating client and API behaviour and investigating roles, inputs and workflows in parallel. The tester oversees the work, approves sensitive activity and validates every result before it can appear in the Adversify report.
What happens next?
Have your mobile app scoped and quoted
Tell us the platforms, build availability and distribution method, environments and APIs, user roles, release date and the sensitive functions or information that matter most. A penetration tester will reply within one working hour to confirm the assessment boundary and prepare a quote against agreed deliverables.
- Scoped to your app and agreed before testing
- CREST-accredited for penetration testing
- Cyber Essentials, based in York
A penetration tester will talk through the builds, platforms and user roles before we prepare a quote.