Penetration Testing Red Team Assessments NGX VAPT Assessments Security Advisory Security Training Architecture Review
Healthcare Capital Markets Banking & Finance Government Telecommunications
Blog Framework Contact Us
OWASP MASVS MASTG OSCP+ CPTS
Android and iOS app security testing

Mobile Application Penetration Testing

Scope a Mobile App Test What We Test
Mobile Security

What a mobile application penetration test covers

We work through the app the way an attacker would: first, we pull the binary apart, watch what it writes to the device, intercept what it sends, and probe the servers it talks to. 

Assessment Scope

The six areas we test by hand

Local Data Storage

Tokens, PINs, card data and personal records cached in SQLite databases, shared preferences, plists and logs.

Insecure Communication

TLS configuration, certificate validation and pinning. Whether traffic can be read or altered by an attacker on public Wi-Fi or a hostile network.

Authentication & Sessions

Login auth flows, biometric fallback, token lifetime and device binding, session persistence.

Tampering & Reversing

What the decompiled binary reveals: hardcoded secrets, disabled checks, and whether the app can be repackaged and re-signed to run modified.

Platform API Misuse

Exported components, deep links, WebView settings, clipboard and IPC. 

Backend APIs

The endpoints behind the app carry the real business logic: transfers, limits, account data. 

Smartphone under mobile application penetration testing with security analysis on screen
Two Platforms

Android and iOS applications fail in different ways

An Android package is straightforward to unpack and read, so hardcoded keys and debug leftovers are found relatively quickly. Android also carries the weight of the second-hand market: a large share of devices in Nigeria run older OS versions that no longer receive security patches, and an app that depends on the platform for protection inherits every one of those flaws. Exported activities, intents and backup flags can give a malicious app installed on the same phone a pathway into yours.

iOS security is tighter by default, and that is exactly why testing it matters: some dev teams assume the sandbox has done the work for them. Keychain entries stored under the wrong protection class, App Transport Security exceptions added during debugging and never removed, and sensitive data left in screen snapshots or the pasteboard all pass functional testing. On a jailbroken device, the sandbox security assumptions would fall away entirely.

We test both builds against the same MASVS profile, so the report is written as one assessment of one product rather than two disconnected exercises.

Beyond the Binary

Testing the backend APIs is half of the work

Every screen in the app is a front end to a request, and the hope is that authorization lives on the server, not the device. The binary can be hardened to a high standard and the product still broken, because an attacker with an intercepting proxy is not using your app at all; they are speaking to your API directly. In our experience, the findings that have real impact (account takeover paths, object-level authorization failures, logic abuse in transfers and limits) are located in the API layer more often than in the app itself.

For that reason the endpoints the app calls are in scope by default, tested with the same depth as our dedicated API penetration testing service. Where the same backend also serves web, USSD or agent channels, we check whether a control enforced in the app, a transaction limit or an OTP step for instance, is actually enforced on the wire. 

Evidence

Verified findings, then a retest

AI analysis extends static review and test-case coverage. Senior penetration testers verify every finding at runtime, trace its impact through the backend APIs, and document the proof of concept: the request, the response, and in some cases, the screenshot. After remediation, we retest the findings as part of the engagement, and the retest reports states what was fixed and what issues remains open. The full engagement structure, from scoping through retest, is set out on our testing methodology page.

Executive summary for management and board review
Technical report with CVSS v3.1 scoring and PoC 
Findings  aligned to OWASP MASVS controls
Prioritized remediation roadmap
One round of retesting included
Post-assessment consultation call with your engineers
FAQ

Mobile app testing questions, answered

Do you need our source code to test a mobile app?

No. Most engagements run grey box: we test the release build the way an attacker would, decompiling the binary rather than reading your repository. If you can share source we will use it, because it shortens the path from symptom to root cause, but it is not a requirement.

Do you test both Android and iOS?

Yes. Both builds are tested if available, and reported as one assessment, with platform-specific findings marked as such.

Does a mobile app test cover our backend APIs?

Yes, the endpoints the app calls are in scope by default. The app is a client; the controls that stop fraud live on the server, so a test that stops at the binary misses the half of the product attackers care about most.

Will testing disrupt our production app?

We normally test against a staging or UAT build with test accounts, so customers see nothing. Where production is the only option, we agree rules of engagement, accounts, and timing in advance, and destructive testing are not included.

Ready to test your app?

Send us the platforms, we will come back with a scoped plan and a timeline that fits it.

Request a Consultation