What do you need in order to test a mobile app?

A release or release-candidate build, test accounts for the roles in scope, and any guidance required to reach the flows that matter. Testing on a modified device or an emulator is used only when it is relevant and you have allowed it. We do not need your signing keys, and we will not ask for a production user's session.

Do you test iOS and Android in one engagement?

Only if both are in the scope. The two clients can share an API and still store data differently, pin certificates differently, and hide different debug surfaces. Testing one platform does not speak for the other. If they share a backend, the API findings are reported once, against the API, and referenced from both.

Do you follow the OWASP MASVS?

We use the OWASP Mobile Application Security Verification Standard and the Mobile Application Security Testing Guide as the map of coverage: storage, cryptography, authentication, network, platform interaction, and code quality where it changes exposure. A MASVS level is a way to describe what was tested. It is not a certification we hand you.

Will you reverse engineer the binary?

When the question requires it and the rules allow it, yes. The point is to see what the client trusts and what it stores, not to produce a novelty write-up of the binary. We stay inside the build you gave us. Store listings and public reviews are not a substitute for that build.

What if the serious issue is on the server?

Then the finding is written against the API, not blamed on the screen that called it. A mobile test that ignores the API misses the part that usually holds the data. If the API deserves its own engagement, we will say so and point you at API penetration testing rather than hide the server inside a client report.

Mobile App Penetration Testing (iOS & Android)

What is mobile app penetration testing?

Mobile app penetration testing is an authorized test of the build you ship and of the services that build talks to. It asks what the application stores on the device, what it trusts about its transport and its runtime, and what its API will allow with the session the application holds. The result is a report a mobile engineer can reproduce and a leader can prioritize. Review of a public store listing is not that test.

What we test

Local storage, backups, and logs come first, because that is where session material and personal data quietly land. Transport follows: whether the client accepts a certificate it should reject, and whether a sensitive call can be made outside the channel the design describes. Authentication and session handling on the device and on the server are in scope. So is the platform surface: intents, URL schemes, WebViews, and the debug or admin functions a build sometimes ships with.

The API is part of the test. A mobile test that ignores it misses the part that usually holds the data. Server-side issues are reported against the API. If that surface is large enough to be its own question, the right engagement may be an API penetration test alongside the client, and we would rather split them honestly than bury the server in an appendix.

The OWASP MASVS and MASTG are the coverage map. We name the area a finding sits in so your team can see what was looked at. Device and OS versions are named in the scope so a finding can be reproduced on the same ground.

Approach and standards

You give us a release or release-candidate build and accounts. Grey-box is the usual shape. We do not need signing keys. A modified device or emulator is used when the check needs it and you have allowed it, for example to see what the client stores after login. We do not root a device as theater.

Black-box testing of a store binary, without accounts, answers only what an outsider can do before they are a user. That is rarely the question you actually have. White-box access to the project is useful when a finding needs to be traced to a call, and it is agreed separately.

The engagement still follows the methodology: written scope, rules, a report, a retest against the build you send back. A later build is a different binary. The retest says which build we opened.

We will map findings to a control set you name, including MASVS categories or a customer questionnaire. The map is not a store-review approval and it is not a certification. If a buyer in Qatar or France has handed you a questionnaire, bring it. The Doha and Marseille offices use the same method.

How long it takes and what affects the price

One application on one platform, with its API, is often six to twelve testing days plus reporting. The second platform is additional scope. A complex offline mode, a hardware accessory, or a large set of roles adds time. The contract names the window and the build identifier.

Price follows the number of platforms, the size of the API the client depends on, whether a modified-device setup is required, and how many roles must be walked. Two skins over one API are cheaper to reason about than two clients with two backends. We will tell you which of those we heard you describe.

What you receive

You receive the build and platform in the scope, a technical report that separates client issues from server issues, a short summary, and a retest against the agreed build. Evidence is enough for an engineer to repeat the step. We do not attach a user’s data to prove the point. The document types are the same ones described on the methodology page.

When to choose this

Choose this when you ship an iOS or Android application and you need to know what that client stores and trusts. Choose a web application penetration test when the product is a site and the mobile client is a thin wrapper you are willing to treat as a browser. Choose an API test alone when there is no client, or when the client is out of scope on purpose. If you are about to submit a build and you want the test to match that binary, say so on the contact page and put the build identifier in the scope.