Mobile App Penetration Testing Checklist: What to Check Before You Buy

Before you sign off on a mobile app penetration testing checklist from a supplier, check it covers five areas. These are local data storage, authentication and sessions, network traffic and certificate handling. Add the backend API and platform-specific checks run separately for iOS and Android. A quote that skips any of these is scoped too thin. So is one that treats iOS and Android as a single combined test.

That matters because the checklist agreed at scoping time is what actually gets tested. Businesses commissioning their first mobile assessment often find out later that “mobile testing” meant an automated scan of the app store listing. It was not a hands-on review of the binary and its traffic. Knowing what should be on the list lets you spot that gap before you pay for it.

What “Mobile App Penetration Testing” Should Mean

The closest thing the industry has to a shared standard is the OWASP Mobile Application Security Testing Guide (MASTG). It pairs with the OWASP MASVS standard it verifies against. Ask a prospective tester whether their methodology maps to this, and to what verification level. It’s a fast way to separate a scoped manual assessment from a rebadged automated scan.

Two testing methods should both appear in the scope. Static analysis means decompiling and reading the app without running it. Dynamic analysis means running it on a real or jailbroken device and watching what it actually does. Ask specifically whether both are included, because some cheaper quotes only cover the static half.

The Mobile App Penetration Testing Checklist to Hold a Quote Against

Local data storage

Sensitive data sitting unencrypted in shared preferences, SQLite databases, cache files or logs is one of the most common findings in mobile testing. It comes up often enough that OWASP gives it its own category in the Mobile Top 10. Confirm the scope explicitly includes pulling apart local storage on a test device, not just reviewing source code.

Authentication and session handling

Improper credential handling currently ranks as OWASP’s top mobile risk. A proper test checks whether biometric login can be bypassed. It checks whether sessions expire sensibly, and whether tokens ever leak into logs.

Network communication

Ask whether the test includes intercepting live traffic with a proxy. Ask too whether certificate pinning, if the app uses it, gets tested for bypass rather than just confirmed to exist. Pinning is a useful control, not a guarantee, and a good tester will say so plainly.

The backend API

A mobile app is a thin client for a backend, and most of the real risk sits there. Broken authorisation between accounts and endpoints that trust whatever the client sends them are common culprits. If your app leans on a substantial API, ask whether that needs a separate API penetration test alongside the mobile work. Don’t assume it comes free.

iOS and Android, tested separately

These are different operating systems with different failure modes. A credible scope treats them that way. On iOS that means Keychain usage, URL scheme handlers and App Transport Security configuration. On Android it means working from the decompiled APK to check exported activities, content providers and broadcast receivers that other apps could reach. A single combined day rate covering both platforms properly is a red flag, not a bargain.

Third-party SDKs

Analytics, advertising and payment libraries run with your app’s permissions. Most of them are not written by your own team. OWASP now tracks supply chain weaknesses as a distinct mobile risk category, so ask whether bundled SDKs are in scope, not just your own code.

Privacy declarations match reality

Both app stores now require developers to declare what data their app collects. Google Play’s Data safety section is one example. A good test checks whether the app’s actual behaviour matches what has been declared. This catches collection that a bundled SDK does quietly in the background.

Resistance to tampering and reverse engineering

Ask whether the scope covers how hard the binary is to pull apart once it is published, since anyone can download and decompile it. This means checking whether the app detects a rooted or jailbroken device. It also means checking how much obfuscation protects the code, and whether a debugger can attach to a production build. A supplier who has never mentioned this side of testing probably hasn’t scoped it in. It is worth asking directly rather than assuming it is bundled in by default.

What a Realistic Scoping Conversation Looks Like

A supplier who understands mobile testing will ask you questions before they quote a price. How many screens and user roles does the app have? Is there a separate API, or does it share one with a web product? Do you need both platforms tested, or just one? Is source code access on the table for a faster, deeper white-box test? Or is this a black-box test with no code access? If a quote arrives without any of those questions being asked, the checklist behind it was probably assumed rather than scoped to your app.

Timeline is worth asking about too. A straightforward app with standard authentication usually takes less time to test properly. But one with custom protocols, multiple user roles or offline functionality takes longer. A quote promising full coverage of both platforms in a couple of days, whatever the app does, is scoping to a price. It isn’t scoping to the checklist.

What a Finished Report Should Give You

Beyond the checklist, ask what the deliverable looks like. Findings should be ranked by real-world severity. They should be reproducible with clear steps, and written so your developers can act on them without a security background. A retest after remediation should be part of the conversation from the start, not an unexpected add-on cost once the report lands.

Aardwolf Security is a UK penetration testing firm. It scopes mobile application penetration testing against exactly this checklist for UK businesses shipping iOS and Android apps. If you have a quote in hand and want a second opinion on it, get in touch and we’ll talk through the scope.

Frequently Asked Questions

What questions should I ask a supplier before commissioning a mobile test?

Ask whether both platforms are tested separately, and whether static and dynamic analysis are both included. Ask whether the backend API is in scope, and what a retest costs once fixes are made.

Is testing one platform enough if my app is mostly used on iOS?

Only if you genuinely have no meaningful Android user base. Otherwise both platforms need their own pass, since the same code can fail differently on each.

How do I know if a quote is scoped too thin?

Watch for a single flat day rate covering “mobile testing” with no platform breakdown. Watch too for no mention of dynamic testing on a device, and no reference to a recognised methodology such as OWASP MASVS.

Should the backend API be quoted separately?

Often yes, especially if the API is large or used by more than the mobile app. A mobile test typically covers how the app calls the API, not a full independent API assessment.

How often should I re-run this checklist against a live app?

Do it after any release touching authentication, storage or networking. Do it at least annually regardless, since new vulnerability classes and platform changes emerge over time.

What if a supplier won’t explain their methodology?

Treat it as a warning sign. A tester confident in their process will happily walk you through how the checklist above maps to what they do. They’ll usually point to a recognised standard. Vague answers about proprietary tools, with no mention of manual testing, are worth pushing back on before you sign anything.