Mobile app penetration testing
A mobile penetration test is two engagements sold as one: the application on the device, and the backend it talks to. The device half produces the interesting screenshots and the backend half produces the findings that would actually hurt you.
A mobile application penetration test in Canada costs $12,000 to $30,000 CAD per platform. The first decision is whether you need both platforms tested at full depth. If your iOS and Android apps are built from one cross-platform codebase and talk to the same API, the second platform is a shorter engagement checking platform-specific storage, transport and hardening, not a repeat of the whole test.
$12,000 to $30,000 Per platform, CAD
40 to 60% What a second platform typically adds
The backend Where the serious findings actually are
The two halves, and which one matters
Client-side testing looks at the application package: how it stores data, how it authenticates, what it logs, whether it validates the server it connects to, and how much of it can be understood or altered by someone holding the device. Server-side testing is an API test of whatever the app calls.
The severity distribution is lopsided. A client-side finding usually requires an attacker to have the device, or to have compromised it, which is a real risk for a lost phone and a narrow one otherwise. A server-side finding is exploitable by anyone with an internet connection and a copy of your app, which is everyone. If the budget only stretches to one, test the backend. The cost page makes the same argument about spending day rate where the findings are, not where the demo looks best.
What that does not mean
Client-side testing is not optional for everyone. If you are in payments, health, or anything where a determined user gaining an advantage matters, the device half is where you find out whether your controls survive contact with a rooted phone. Same if you hold credentials or health information in local storage for offline use. The backend is the default priority, not the only one. Where card data is involved, PCI DSS decides the question for you.
What the client-side test covers
| Area | What is being checked |
|---|---|
| Local storage | Tokens, credentials, personal information and cached responses written to the device without protection |
| Keychain and keystore usage | Whether platform key storage is used properly, and whether items survive uninstall or backup |
| Transport security | Certificate validation, pinning where appropriate, and whether the app fails closed on an untrusted connection |
| Authentication on the device | Biometric gates that only hide the interface, session persistence, behaviour after a remote password change |
| Reverse engineering resistance | What can be learned from the package: endpoints, keys, feature flags, business logic |
| Runtime manipulation | Whether client-side checks can be bypassed by altering the app while it runs |
| Inter-process surfaces | Exported components, deep links and custom URL schemes that other apps can call |
| Logging and leakage | Sensitive values written to system logs, crash reporters, analytics or screenshots |
Testing is normally done on a rooted or jailbroken device or emulator, the only way to inspect storage and observe runtime behaviour. That is the position of an attacker who owns the hardware, and everything on the device should be scoped on the assumption they do.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
The finding every mobile report contains
Something sensitive is in the package. An API key, a third-party token, a signing secret, sometimes a database credential from an earlier version of the app that nobody removed. Build tooling makes it easy, the value was needed at runtime, and nobody asked whether it needed to be in the binary.
The right response is not obfuscation. Anything shipped to a device is readable by whoever holds it, given time. The response is to move the secret to the server and give the app a short-lived credential, or to accept that the value is public and make sure it cannot do anything on its own. A report that recommends obfuscating a key rather than removing it is telling you to hide the problem. Push back during the readout.
Standards a firm should be able to name
The OWASP Mobile Application Security Verification Standard and its testing guide are the published references for this work, and a firm doing mobile testing seriously will map their coverage to a verification level from it. That mapping is what turns "we tested the app" into a coverage claim your auditor can read. Ask which level was targeted and which requirements were out of scope. A firm that answers with a grey box description and no named standard is describing an approach rather than a coverage claim.
What mobile testing costs
| Scope | Tester days | Typical range |
|---|---|---|
| One platform, client side only | 4 to 7 | $8,000 to $18,000 |
| One platform, client plus backend API | 7 to 12 | $14,000 to $30,000 |
| Second platform, shared codebase and same backend | 2 to 4 | $4,000 to $10,000 |
| Second platform, separately built native app | 4 to 7 | $8,000 to $18,000 |
Ask what a retest of the fixed build costs and how long you have to use it. A mobile fix waits on an app store review, which can consume half a 30 day window. The terms are on retest and remediation verification, and the dates come out of the retest planner.
Supply builds rather than store listings. A debug-symbol build for the client work and a release build to check what ships are both useful, and test accounts have to exist before the window opens or you lose days to onboarding. The scoping questionnaire produces a document covering all of that. Send it when you collect quotes.
When you should not buy a mobile test at all
If your app is a thin client over an API you have already had tested properly, and it stores nothing sensitive on the device, a full mobile engagement will mostly confirm that. The findings will be certificate pinning, logging and local storage hygiene, which are real but rarely what gets a company compromised. Spend the budget on the API instead and revisit mobile when the app gains offline data, a payment path or platform-specific authentication. A firm that will tell you this is worth more than one that quotes both platforms without asking.
Scope a mobile test
Tell us the platforms, whether the codebase is shared, and whether the backend is in scope, and we will put one scope in front of Canadian firms.
Get matchedCommon questions
Do we need to test both iOS and Android?
If both are published, both are in scope for a customer or an auditor asking whether your product was tested. The cost is not double when the codebase is shared, because the backend work is done once and the second platform is a shorter piece checking storage, transport and platform hardening. If the two apps were built separately by different teams, price them as two engagements, because that is what they are.
Is testing on a jailbroken device realistic?
Yes, for the threat it models. The attacker who matters for client-side findings is someone with physical possession of a device or a user running a modified app to gain an advantage in your product. Both hold a device they control. Testing only on a stock device would mean reporting that your storage is protected by the platform, which is true right up until the person holding the phone decides otherwise.
Does certificate pinning matter?
It raises the cost of intercepting traffic on a device the attacker controls, which is worth something for payments and health apps. It does not protect your API, because pinning can be removed from an app by anyone willing to spend an afternoon on it. Treat it as a friction control and never as the reason an endpoint is safe. A tester will normally ask for a build with pinning disabled so that the backend can be tested properly, then confirm separately that pinning works in the shipping build.
Will an app store review catch security issues?
No. Store review checks policy compliance, permissions declarations and privacy disclosures. It does not test your authorization model, it does not look at what your backend returns, and it does not read your code for embedded secrets. Passing review tells you the app is publishable, not that it is safe.
How does mobile testing fit a SOC 2 or ISO 27001 audit?
If the mobile app is part of the system described in your scope statement, it belongs in the annual testing evidence and an auditor can reasonably ask why it was excluded. The practical arrangement for most companies is one engagement covering the backend API and the mobile clients together, with a single report, so the coverage claim matches the scope statement in one document rather than three.