Mobile Application Pentest (MOBILE VAPT)

A mobile app pentest covers both iOS and Android, and they are scoped as two targets because they are two codebases with different platform risks. Testing one and assuming the other is equivalent is a common and expensive shortcut.

iOS

Keychain use, secure enclave and biometric flows, jailbreak detection, custom URL schemes and what the app writes to caches and backups. Several of these behave differently on hardware, which is why we test on real devices and not only in simulators.

Android

Keystore use, exported activities and services, deep links, root detection, shared preferences and what lands in a device backup. The bundle is decompiled and read for hardcoded credentials, keys and debug code that shipped.

A cross-platform framework still produces two binaries with two sets of platform behaviour, so it is scoped the same way.

Yes, a mobile app pentest always includes the backend API, and it is priced in. Roughly two thirds of the serious findings on a mobile engagement are server side, so an app-only test tells you about the wrapper instead of the risk.

The client is not a trusted environment. It runs on hardware belonging to the user, who may be the attacker, so any control implemented only in the app, and any endpoint that trusts a client-side check, is a server-side finding waiting to be written up.

The endpoints the app calls are tested directly for authorisation and logic as a full API assessment, with a token per role, rather than only through the app's own screens.

Yes, a mobile app pentest gets past certificate pinning, because pinning raises the cost of interception without preventing it on a device we control. We test with pinning in place and with it removed, and report both.

What pinning protects is worth knowing: it stops interception on a network the attacker controls but the device does not. What the server does once pinning is bypassed is the part that matters, because that is the position a motivated attacker with their own handset is in.

A pinning implementation that holds for a long time under a real attempt is reported as such. One that falls back to the plain trust store when it cannot validate is reported as a finding, since that is the common failure.

A mobile app pentest does not need the source code, but having it shortens static analysis and improves coverage. Without it we decompile the binary, which finds most of the same things and takes longer.

Hardcoded credentials, key handling, cryptographic use and debug code are all readable from a decompiled bundle. Source makes the review faster and lets us follow a suspicious call to where the value is used rather than inferring it.

For a first engagement on a large application, white box with source is usually worth the extra disclosure. For a repeat test on a stable codebase, grey box with test accounts on both platforms is the standard.

A mobile app pentest typically takes two to three weeks per platform, including the backend and reporting. The driver is the number of distinct features and roles, not the size of the download.

Each platform gets its own static analysis, storage review, transport testing and runtime protection work on real devices. The backend API is tested once, but every role is exercised against it, so role count moves the estimate more than screen count does.

Supplying source code and a release build up front shortens the static phase. The retest is quoted alongside the initial scope and runs once your fixes have shipped.

A mobile app pentest runs against the production backend only by written agreement, and preferably against a staging backend with production-equivalent configuration. Where staging differs materially we say so, because a test against a different configuration is a test of a different system.

The app itself is always tested on devices we control, so nothing about the client side touches your users. The backend is where care is needed: authorisation testing creates and reads records, and rate limit work generates traffic.

Denial of service techniques are excluded by default. The rules of engagement fix the hours, the excluded techniques and the deconfliction route before work starts, and no production change is made without agreement.

A mobile app pentest assesses root and jailbreak detection and reports how long it holds under a real attempt. We do not treat bypassing it as a finding in itself, because it is a speed bump by design and grading it pass or fail misrepresents what it is for.

The same applies to anti-debugging, anti-hooking and obfuscation. Each is rated on the effort it cost to remove, so you can judge whether the protection is proportionate to what the app guards.

What we do report as findings are the controls behind the detection: a server that trusts the app's own integrity claim, a secret that is exposed once the check is gone, or a business rule enforced only in the client.

A mobile app pentest can test a pre-release build, and that is the ideal time. We accept builds through TestFlight, an internal track on Google Play, or a direct binary, so the findings land before the release rather than after it.

Release builds

The release configuration is what ships, and obfuscation, pinning and root detection are often only switched on there. We test that build to see the protections your users actually get.

Debug builds

A debug build makes instrumentation faster and is useful alongside the release build, but a test of only a debug build says little about what an attacker with the store version faces. We ask for both where you can provide them.

A mobile app pentest delivers findings for the client, the storage layer, the transport layer and the backend, each with severity, reproduction steps and named owners, plus platform-specific remediation guidance and a retest once your fixes land.

The report opens with an executive summary and closes with a remediation order that reflects real risk rather than raw CVSS. Findings are mapped to MITRE ATT&CK, and every one of them was proved on a device or against the backend, never asserted from tool output.

Remediation guidance names the platform mechanism to use, keychain or keystore for example, because a fix written for the wrong platform is a fix that does not ship. The retest is quoted up front and a signed attestation of testing is issued at the end.

A mobile app pentest examines every place the app writes data on the device: databases, shared preferences, caches, logs, keychain and keystore use, and what lands in a device backup. The question is what a stolen unlocked device gives up, and what survives a backup to somewhere less protected.

Session tokens in plain text, cached responses containing personal or financial data, and secrets written to logs are the recurring findings. Each is tested on real hardware, because keychain and secure enclave behaviour differs from the simulator.

Clipboard and screenshot handling are reviewed alongside storage, since a card number copied to the clipboard or captured in the app switcher leaves the app's control the same way a file does.

A mobile app pentest tests against the OWASP Mobile Application Security Verification Standard, with the test cases drawn from the Mobile Application Security Testing Guide. The level is agreed at scoping according to what the app handles.

MASVS L1

The baseline for every app: storage, cryptography, authentication, network, platform interaction and code quality. Any app that handles user data should clear it.

MASVS L2

Defence in depth for apps handling payments, health records or other sensitive data. It adds stricter storage, authentication and network requirements on top of the baseline.

MASVS R

The resilience controls: root and jailbreak detection, anti-tampering, anti-debugging and obfuscation. These are rated on how long they hold, not pass or fail, which is the only honest way to report them.

In the UAE a mobile app pentest is expected under the CBUAE regime for banking and payment apps, ADHICS for Abu Dhabi healthcare apps, and PCI DSS wherever the app or its backend touches card data.

CBUAE

Licensed banks, payment institutions and stored-value facilities must run independent periodic security testing with findings tracked to closure. A customer-facing app is among their most exposed assets, and examiners read the evidence chain for it.

ADHICS

Abu Dhabi healthcare providers and payers must protect health information across its lifecycle. Testing is designed so that clinical availability is never the thing at risk, which is why the backend work is scheduled and agreed.

PCI DSS

Any environment that stores, processes or transmits cardholder data needs testing at defined intervals and after significant change. Scoping decides cost here more than anything else does.

Dubai government apps fall under the ISR published by DESC, and federal entities under the UAE IAS, which tenders still call NESA.