Mobile application penetration testing
We test your Android and iOS apps the way an attacker holding a phone would: taking the signed build apart, running it on real rooted and jailbroken devices, and testing the API it talks to. Every finding comes with its fix, and the work is done from our Hyderabad office for companies anywhere in India.
- Platforms
- Android and iOS, one engagement
- Baseline
- OWASP MASVS (L1 and L2)
- Typical duration
- 5 to 10 working days
- Starts from
- INR 27,000 + 18% GST
Last reviewed
Pathtest phone → F-01 → F-02 → back end
Also mappedsession token · mobile API · F-03 · app binary
- F-01Certificate pinning switched off with a runtime hook, so the app's API calls can be read and replayedLow
- F-02A mobile API endpoint returns another user's records when the ID in the request is changedHigh
- F-03A third-party API key hard-coded in the app binaryMedium
- ChainOther users' records read through the app's own APIHigh
01 / Who needs it
Who needs mobile application penetration testing
A mobile app is software you hand to anyone who downloads it. They can take the build apart and watch it run on a phone they control, so whatever the app stores, sends or assumes about its back end is open to inspection.
Mobile binaries leak, and they leak in places teams rarely look: keys written into the code, tokens left in local files, logs that say too much, and certificate pinning that gives way to a runtime hook. A mobile application penetration test finds those leaks first, and checks that the servers behind the app enforce the rules its screens only appear to apply.
Teams usually ask for a mobile test when one of these describes them:
Your app moves money or holds health records
Fintech and healthcare apps keep tokens, account details and personal data on phones you do not control. A weakness in the app is repeated on every phone that installs it.
Your API was built for the app alone
A back end written for a mobile client is often more exposed than the web front end, because its developers assumed only the app would ever call them. Someone holding the app's traffic can call those endpoints directly, with any values they like.
A release is heading to the stores
Testing the build before it ships, whether a production-signed release, a beta or a debug build, lets a serious flaw be fixed before that version sits on users' phones, where old versions can linger long after an update is published.
Your security leans on the client
Certificate pinning, root and jailbreak detection and obfuscation slow an attacker down, but none of them is a security boundary. If the real protection lives only inside the app, the test shows what happens once it is switched off.
Your app opens from links
Custom URL schemes, Android exported activities and OAuth callbacks delivered by deep link let other apps and web pages hand your app instructions. Each of those entry points needs to refuse what it should not accept.
A customer or auditor has asked
Enterprise security questionnaires and audits ask whether the app, and not only the website, has been tested by someone independent. A recent report gives you that answer in writing.
The mobile apps we test come from fintech, healthcare, media and entertainment, logistics, education and retail. The method holds steady across them; what changes is the prize: balances in a payments app, records in a health app, paid content in a media app.
- Fintech
- Healthcare
- Media and entertainment
- Logistics
- Education
- Retail
02 / What we test
What a mobile app test covers
A mobile test is half app and half API: many issues live in the binary and on the device, and many others in the back end the app talks to. Both layers are tested on one engagement, against OWASP MASVS at L1 and L2, across its storage, cryptography, network and platform controls.
Android app
We decompile the APK, review the manifest for exported activities and other components any app can reach, check signing and obfuscation, and run the app on physical rooted devices to see what it writes to SharedPreferences, local files and the Keystore.
iOS app
We take the IPA apart, read the Info.plist for URL schemes and transport settings, and run the app on physical jailbroken devices to check Keychain entries and their accessibility flags, what lands in NSUserDefaults, and how biometric sign-in is wired.
The back-end API
Once pinning is bypassed, the app's requests are routed through Burp and the back end is tested like any other API: authorization between users and roles, IDOR, mass assignment and rate limits.
Data on the device
After real use, local databases, preference files, caches and logs are read to see whether tokens, personal data or keys sit there in plain text, and whether Keychain and Keystore protections are set as intended.
Network traffic
Certificate pinning, transport security and trust-store handling are checked: whether the app accepts a certificate it should refuse, and how much effort it takes to read and alter its traffic.
Platform and permissions
Deep links, custom URL schemes, inter-process communication and the permissions the app requests are reviewed for ways another app or a crafted link could trigger a privileged action.
On both platforms, static reverse engineering also looks for hard-coded secrets, weak cryptography and debug paths left in the build, and the app's jailbreak and root detection is reviewed along with any tamper evidence.
The OWASP Mobile Top 10 is a short awareness list of the main risk categories for mobile apps. This is where each category is examined:
| Category | Where the test looks |
|---|---|
| M1 Improper Credential Usage | Static analysis for keys and credentials hard-coded in the build, and how the app hands credentials to the back end. |
| M2 Inadequate Supply Chain Security | The dependency audit in static analysis: the third-party libraries and SDKs bundled into the build. |
| M3 Insecure Authentication/Authorization | Back-end testing as each test user: whether the API checks who is asking, not only whether the app hid a button. |
| M4 Insufficient Input/Output Validation | Deep links, inter-process entry points and the API parameters the app sends. |
| M5 Insecure Communication | Certificate pinning, transport security and trust-store validation. |
| M6 Inadequate Privacy Controls | Personal data left behind in local files, caches and logs. |
| M7 Insufficient Binary Protections | Signing, obfuscation, and the strength of jailbreak, root and tamper detection. |
| M8 Security Misconfiguration | The Android manifest and the iOS Info.plist: exported components, URL schemes, debug settings and transport exceptions. |
| M9 Insecure Data Storage | SharedPreferences, NSUserDefaults, local databases, and Keychain and Keystore entries. |
| M10 Insufficient Cryptography | Weak or home-made cryptography found during reverse engineering, and where the keys are kept. |
BERRY9 maps its mobile work to both the OWASP Mobile Top 10 and MASVS. MASVS is the more detailed OWASP standard for verifying mobile app security.
A mobile app rarely stands alone. The web front end that shares its accounts is covered by web application penetration testing; an API that serves partners and other clients as well as the app has its own API security testing service; and the servers and networks the back end runs on are covered by network penetration testing.
03 / Method
How a mobile app test runs
Every BERRY9 engagement moves through the same five phases. On a mobile test the build is taken apart before it is run, and the back end is tested once the app's traffic is in view.
Show details for How a mobile app test runs
Phase 1
Scope and threat model
We settle the platforms (Android, iOS or both), the build (production-signed, debug or beta), the user roles, and whether back-end API testing is included; by default it is. The threat model names what an attacker would want from your app, and the limits on active testing are agreed in writing before any testing begins.
OutputWritten scope and rules of engagement
Phase 2
Static analysis
The binary is decompiled and read without running it. Dependencies are audited, the build is searched for hard-coded secrets, the manifest or Info.plist is reviewed, and signing and obfuscation are checked. The cheap finds turn up here, and they show where the runtime work should dig.
OutputFindings from the binary
Phase 3
Dynamic instrumentation
The app runs on physical rooted Android and jailbroken iOS devices under Frida and Objection. We bypass certificate pinning, dump memory, trace methods and watch the app at runtime: what it writes to disk, what it keeps in memory, and which checks happen only on the phone.
OutputRuntime behavior observed on real devices
Phase 4
API and back-end testing
With pinning out of the way, the app's traffic goes through Burp and the back end is tested as an API in its own right: authorization between users and roles, IDOR, mass assignment and rate limits. Each finding worth reporting is confirmed with a proof of concept.
OutputProofs of concept
Phase 5
Reporting
Findings are mapped to OWASP MASVS, scored with CVSS 3.1 and written up in an executive report and an engineering report. A hardening guide shaped around your build pipeline turns the recurring fixes into checks your team can keep running.
OutputReports and hardening guide
The VAPT methodology page sets out the five phases we follow on every type of test.
04 / Attack surface
Attack surface and common findings
A mobile app exposes more than its screens: the binary, the files it leaves on the device, the links that open it and the API behind it. The findings below recur across mobile engagements; they are described here by what they mean for the business, and the report holds the technical detail.
Show details for Attack surface and common findings
| Finding | What happens | Severity | What your developers get |
|---|---|---|---|
| Insecure local data storage | Tokens kept in plain-text SharedPreferences, session data in NSUserDefaults, or Keychain entries with accessibility flags wider than they need to be. Whoever reaches the app's storage on the device can lift what is kept there. | VariesIt depends on what is stored: a display preference is harmless, a session token is not. | The exact files and keys affected, and the platform storage to use instead. |
| Hard-coded secrets and API keys | Third-party API keys, signing keys and the addresses of back-end admin endpoints embedded in the binary. Anyone who downloads the app can extract them, so a key shipped in the build should be treated as public. | VariesA read-only analytics key and a payment provider's secret key are very different findings. | Each secret, where it sits in the build, and how to move it to the server and rotate it. |
| Certificate pinning that gives way | Even apps with pinning switched on often depend on a single library hook point that a runtime tool such as Objection can disable with one command. After that, every API call the app makes can be read and replayed. | VariesOn its own a speed bump rather than a breach; the risk is whatever the API then allows. | How pinning was bypassed, and the server-side checks that must hold when it is. |
| Deep-link and intent abuse | Custom URL schemes that trigger privileged actions, Android exported activities that any other app can open, and OAuth callbacks delivered by deep link that can be hijacked to bind an account to the wrong person. | VariesAnything from a nuisance to account takeover, depending on what the link can do. | The link or intent that reproduces it, and the validation the app should apply. |
| Back-end authorization gaps | An endpoint the app calls returns or changes another user's records when the ID in the request is edited, or accepts fields the app never sends, such as a role or a price. | HighVisible only once the app's own traffic is in hand. | The request that shows it and the server-side check that closes it. |
Two client-side protections deserve a word of their own. Jailbreak and root detection is defense in depth, not a security boundary: we test whether it works, bypass it, and report both how strong the detection is and what an attacker reaches once it is out of the way. Obfuscation works the same way; it slows reverse engineering down, but it does not make a secret in the build safe to ship.
These topics are written up for engineers in articles on Frida and Objection, jailbreak detection bypass, deep-link weaknesses and the OWASP Mobile Top 10.
05 / What you get
What you get from a mobile test
The deliverables are written for two audiences at once: leadership, who need to know how exposed the app and its users were, and the developers who will ship the fixes in the next build.
Show details for What you get from a mobile test
- An executive report that explains, without jargon, what was tested on each platform, what was found and what it means for the business and its users.
- An engineering report with reproduction steps and a proof of concept for every finding, so your mobile and back-end developers can confirm each issue themselves.
- Severity scored with CVSS 3.1, judged against what the app actually holds and who relies on it.
- Static and dynamic findings cross-referenced with OWASP MASVS, so the coverage of storage, cryptography, network and platform controls is visible, not only the issues.
- A hardening guide tailored to your build pipeline, written so its checks can live in CI as lint rules and dependency audits.
- A remediation matrix listing every finding with its priority, so fixes can be planned into the next releases and tracked.
The sample VAPT report shows how a BERRY9 report is laid out.
Finding F-04 · Android app
Session token kept in plain-text app preferences
- Severity
- Medium
- Affected
- The app's private preferences file
- Tested as
- Signed release build, rooted test device
Steps to reproduce
- Sign in to the app on the rooted test device.
- Read the app's private preferences file from the device storage.
- Find the session token stored there in plain text, and replay it from another client to open the account.
GET /v1/account HTTP/1.1
Authorization: Bearer <device token>
Fix
Store the token through the Android Keystore instead of plain preferences, keep its lifetime short, and let the server revoke it.
Example layout, not client dataCVSS 3.1 · MASVS storage
06 / Price
Price of a mobile application test
Testing a mobile app and its back end starts from INR 27,000 + 18% GST. That is a starting price: larger scopes cost more, and the figure for your app is set in a written proposal after a scoping conversation.
No two apps take the same effort. A single-platform app with a handful of screens and one kind of user is a short engagement; an app shipped on both platforms, with many screens, several roles and a large API behind it, is a longer one. The proposal names the platforms, builds, roles and API hosts in scope, so you know what the figure covers before work starts.
Our VAPT cost guide for India explains how scope turns into a price across every type of test.
Mobile app with its back end
Starts fromINR 27,000 + 18% GST
A starting price; the figure for your app is set in a written proposal after scoping. Four things move it most:
- Platforms. Android, iOS or both: each platform is a separate binary to take apart and run on its own devices.
- Screens. More screens and flows mean more inputs, more stored data and more back-end calls to follow.
- API endpoints. Every endpoint the app calls is tested for authorization, so a large API takes longer than a small one.
- Roles. Each kind of user, such as a customer, an agent or an admin, needs its own test account and its own pass through the app.
07 / What we need
Before testing starts
Most of the preparation is gathering access: a build, an environment and accounts. The sooner those arrive, the sooner the test can begin.
Show details for Before testing starts
What each item is for
The build. Send the signed APK for Android and the IPA for iOS. A production-signed build shows exactly what your users install; a debug or beta build can be agreed instead, and the scope records which one was tested.
The back end. A test environment the app can point at, so back-end testing does not have to run against live customer data, plus the list of API hosts in scope and any third-party services that must be left alone.
The accounts. Test users for each role, so the time goes on what each kind of user can and cannot reach rather than on signing up.
Source code is not required: a mobile test works from the signed binary. If you want a deeper look, the mobile engagement can be paired with a source code review.
What we need from you
- The signed APK or IPA, production-signed, beta or debug, as agreed.
- A back-end test environment the app can connect to.
- Test users for each role.
- The back-end scope: the API hosts in scope, and services to leave alone.
- Signed rules of engagement.
BERRY9 has one office, in Hyderabad, and mobile apps are tested remotely from there on physical test devices, so a team in Bangalore, Chennai or anywhere else in India gets the same test; on-site work can be arranged by agreement. More on VAPT services in Hyderabad.
08 / Turnaround and retest
Turnaround and retest
How long a mobile test takes depends on the platforms in scope, the size of the app and the size of the API behind it.
Show details for Turnaround and retest
- Working days for a typical mobile application test
- 5 to 10
- Android and iOS, tested on the same engagement by default
- 2 platforms
A typical mobile application test takes 5 to 10 working days. An app on both platforms with many screens and a large API sits toward the longer end, and the proposal sets out the schedule for anything beyond that.
Each new signed build
For ongoing engagements, regression tests can be run on each signed build, so a fix shipped in one release is not quietly undone in the next. A retest checks the fixes on the next signed build your team produces.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
09 / Compliance
Mobile testing for audits and compliance
Compliance frameworks rarely mention mobile apps by name. When the app is where customers sign in, pay or share personal data, though, it sits inside the systems those frameworks expect you to protect and test.
Show details for Mobile testing for audits and compliance
Work toward SOC 2, ISO 27001, PCI DSS or the DPDP Act will often raise the question of whether the mobile app and its back end have been tested by someone independent.
SOC 2
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. A mobile report covers the app your customers actually install.
ISO 27001
Annex A control 8.8 of ISO/IEC 27001:2022 covers the management of technical vulnerabilities; findings from the app and its API, tracked to closure, are records that control can draw on. BERRY9 itself holds ISO/IEC 27001:2022 certificate 26MEQVU27; that certificate is ours and does not certify your organization.
PCI DSS
PCI DSS 4.x sets its penetration testing requirements in requirement 11.4, which covers the application layer as well as the network. If your app handles card data, or can affect the systems that do, the test is scoped with those requirements and your assessor in mind.
DPDP Act
India's Digital Personal Data Protection Act, 2023 asks organizations to protect personal data with reasonable security safeguards. Personal data cached on phones and served by the app's API is part of that picture, and the report records that it was checked.
BERRY9 tests; it does not audit or certify your organization, and whether a report satisfies an audit is for your auditor or assessor to decide.
10 / Inquiry
Send us your app's scope and timeline
Tell us which platforms you ship, roughly how many screens and user roles the app has, where its back end runs, and when the test needs to be finished. We will come back with a scope and timeline.
Prefer to talk first? Call +91 86868 92922 or write to contact@berry9.com.
11 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
Do you test both iOS and Android apps?
Yes. Testing both platforms on the same engagement is the default. Android and iOS have different attack surfaces and different classes of bug, but they usually share one back-end API, so testing only one leaves gaps. If you ship on a single platform, the engagement is scoped to that one.
How much does mobile app penetration testing cost?
A mobile application test with its back end starts from INR 27,000 + 18% GST. It is a starting price: the figure for your app depends on the platforms, the number of screens, the API endpoints and the user roles in scope, and it is set in a written proposal after scoping. See the section on Price of a mobile application test above.
How long does a mobile application penetration test take?
A typical mobile application test takes 5 to 10 working days. An app on both platforms with many screens and a large API sits toward the longer end, and the proposal states the schedule. See the section on Turnaround and retest above.
Is the back-end API tested as part of a mobile app test?
Yes, by default. Many mobile issues live in the API the app talks to rather than in the app itself, and testing one without the other is half a test. If the API needs a deeper audit of its own, an API security assessment can be scoped alongside the mobile work.
Do you test jailbreak and root detection?
Yes. We test whether your jailbreak and root detection works, and then we bypass it. Detection is defense in depth, not a security boundary, so the report covers both how strong the detection is and what an attacker can reach once it is bypassed; the protections that matter have to sit on the server.
Do you test on real devices or emulators?
Real devices: physical rooted Android phones and jailbroken iOS devices. Some classes of bug, such as Keychain access patterns, biometric integration and hardware-backed cryptography, only show up on real hardware, and emulators miss them.
Do you need our source code?
No. A mobile penetration test works from the signed binary, which is reverse-engineered as part of the engagement. Source code helps with a deeper review, and the mobile test can be paired with a source code review if you want one.
What do you need from us to start a mobile app test?
The signed APK or IPA, a back-end test environment the app can connect to, test users for each role, and the list of API hosts in scope. The rules of engagement are agreed in writing before testing begins. See the section on Before testing starts above.
Does the test cover the OWASP Mobile Top 10?
The test examines areas that correspond to the ten categories of the OWASP Mobile Top 10, from credential handling and data storage to network communication and binary protections. Findings are cross-referenced with OWASP MASVS, the more detailed OWASP standard for verifying mobile app security. See the section on What a mobile app test covers above.
Do you check the third-party SDKs and libraries inside the app?
Yes, as part of static analysis. The dependencies bundled into the build are audited, and third-party API keys embedded in the binary are among the findings that recur. Third-party services the app calls are listed during scoping, together with any that must not be touched.
Can you test an app before it is published to the app stores?
Yes. The scope names the build to be tested, whether a production-signed release, a beta or a debug build, so an app can be tested before launch as well as after it.
Can the hardening advice be built into our CI pipeline?
Yes. The hardening guide and the pattern catalog we deliver are designed to live in your CI as lint rules and dependency audits, and for ongoing engagements regression tests can be run on each signed build.
Will a mobile app penetration test make us compliant?
A test does not make you compliant on its own. The report is evidence that the app and its back end were tested, which supports SOC 2, ISO 27001, PCI DSS or DPDP Act work; BERRY9 tests, and the audit decision belongs to your auditor.
Can you test our mobile app if we are not in Hyderabad?
Yes. Mobile apps are tested remotely from our only office, in Hyderabad, on physical test devices, with the back end reached over the internet or through access you provide. Teams in Bangalore, Chennai and the rest of India get the same test, and on-site work can be arranged by agreement.