Short answer. A web or API pentest does not cover your Android app. It covers the server your Android app talks to. The mobile build adds three attack surfaces that do not exist on your web stack: the APK itself, which you ship to every attacker who installs it; the data the app writes to a device you do not control; and the platform runtime, which is where root detection, certificate pinning, exported components and deep links live. Android and iOS are two scopes because they are two builds with two storage models and two sets of platform controls. Testing follows the OWASP Mobile Application Security Verification Standard and the OWASP Mobile Application Security Testing Guide, and the report evidences ISO 27001:2022 A.8.8 and A.8.29 plus SOC 2 CC7.1.
Cybersecify is a founder-led penetration testing firm in Bengaluru serving AI-first and API-first SaaS startups. This is the buyer-side explanation of what an Android application pentest is, what it covers, and when you actually need one. If you want to see the deliverable before you talk to anyone, our sample report is public and needs no NDA.
Here is the conversation that usually starts this. An enterprise customer sends a security questionnaire. Question 40 asks for the most recent penetration test of the mobile application. You have a pentest report. It covers your web app and your API, because that is what you bought last year, and the scope section says so in the first paragraph. The customer’s security reviewer reads the scope section too.
Does a web pentest cover my Android app
No, and the scope page of your existing report is what gives it away.
Your Android app and your web app usually talk to the same backend. That shared server side is genuinely covered by a web or API pentest: the authentication endpoints, the authorization logic, the business rules, the injection surface. If your API was tested properly, that work transfers.
What does not transfer is everything that only exists because there is an app on a phone.
The binary is in the attacker’s hands. You ship the APK to every person who installs it. Pulling it off a device is trivial, and once it is on a laptop it can be unzipped, decompiled back to readable Java, and searched. Every string constant, every embedded endpoint, every configuration file and every credential that a developer thought was safe because it was compiled is readable. There is no equivalent on your web stack, where the server-side code stays on the server.
The app writes to a device you do not control. Android apps store data in SharedPreferences, SQLite databases, internal and external storage, cache directories and log output. Session tokens, personally identifiable information, API responses and debug traces all end up there in real applications. On a rooted device, or through a backup if the backup flag is set carelessly, that is all readable. Your web application has no local storage story of this kind.
The platform is adversarial. The user controls the operating system. That is what makes root detection, certificate pinning, anti-tampering, exported components and deep links into real security controls rather than theory, and it is why the OWASP mobile standards have an entire control group for resilience that has no web equivalent.
A web pentest does not test any of those three, because none of them are reachable from a browser. This is the same structural point as API pentest versus web app pentest: different surface, different scope, different test.
Why are Android and iOS two separate pentest scopes
Because they are two builds, and a finding in one is usually not present in the other.
The storage models are different. Android has SharedPreferences and the Android Keystore. iOS has the Keychain with its own accessibility classes and file Data Protection classes. A secret stored badly on Android is stored badly in a completely different place on iOS, and the fix is different code.
The platform interfaces are different. Android exposes activities, services, broadcast receivers and content providers to other applications on the device, and each of those can be exported deliberately or by accident. iOS exposes custom URL schemes, Universal Links and app extensions. The classes of bug are not the same.
The resilience controls are different. On Android, resilience testing means root detection, anti-debugging and tamper detection. On iOS it means jailbreak detection. Teams frequently implement one properly and the other not at all.
Even in a React Native or Flutter codebase where most business logic is shared, the platform bridge, the storage layer, the network configuration and the packaging are per platform, and that is precisely where mobile findings cluster. Shared code reduces the delta. It does not remove it.
That is why we quote them as two scopes. One scope is the Startup Pentest at INR 74,999. Android plus iOS is the Growth Pentest at INR 1,79,999 over 10 business days.
What gets tested in an Android app pentest
Testing follows the OWASP Mobile Application Security Verification Standard, currently v2.1.0, as the requirements standard, and the OWASP Mobile Application Security Testing Guide, currently v2.0.0, as the testing methodology. MASVS organises requirements into eight control groups, and every finding we report is tagged with the group it violates plus a CWE identifier and a CVSS score, so your engineers can look up the OWASP source directly rather than taking our word for it.
Concretely, the work splits into static analysis of the package and dynamic analysis on a real device.
Static analysis of the APK. Decompiling the package and reading what is inside it. The AndroidManifest is the first stop: which components are exported, which permissions are requested, whether the app is debuggable, whether cleartext traffic is allowed, whether backups are permitted. Then the code and resources are swept for hardcoded API keys, secrets, private endpoints, test credentials and internal URLs. Third-party SDKs are inventoried and checked against known vulnerable versions, which matters more than most teams expect because an analytics or advertising SDK can collect and transmit data your privacy declaration never mentioned.
Local storage. What the app actually writes to the device during normal use, and whether any of it is sensitive. Session tokens in SharedPreferences, personal data in an unencrypted SQLite database, full API responses in a cache directory, authentication material in log output, and files written to external storage where any other app can read them. This is the single most common source of real findings in Android engagements.
Cryptography and key handling. Whether the Android Keystore is used at all, whether it is used correctly, and whether keys can be extracted or the key-backed operations bypassed. Hardcoded keys, weak or custom algorithms, and predictable initialisation vectors all show up here.
Network security and certificate pinning. Whether TLS is enforced everywhere, whether the network security configuration permits cleartext to any domain, and whether certificate pinning is implemented. Pinning then gets tested the way an attacker tests it, by attempting to defeat it at runtime with an intercepting proxy in place. Pinning that can be disabled by hooking one function is worth knowing about, because the answer determines whether your API is effectively public.
Root detection and resilience. Whether the app detects a rooted device, and whether that detection survives a determined attempt to bypass it. This matters commercially for fintech, payments and anything with an anti-fraud requirement, and matters much less for a general-purpose SaaS client. We tell you which case you are in rather than inflating the severity.
IPC and exported components. Whether another application installed on the same device can invoke your activities, services, broadcast receivers or content providers, and what it gets when it does. An exported content provider that returns user records to any caller is a real finding with a real exploit, and it is invisible from outside the device. Deep links get the same treatment: whether a crafted link can reach an authenticated screen, carry an injected parameter, or trigger an action without confirmation.
Authentication and authorization on the mobile surface. Token storage, token lifetime, refresh handling, biometric gating and whether any authorization decision is made on the client that should be made on the server. Client-side authorization checks are one of the more common ways a mobile build weakens an otherwise sound API.
Do I need an Android pentest to publish on Google Play
Not to publish. It is worth separating three things that get conflated in vendor marketing.
The Data safety form is a declaration, not a test. Google Play requires developers to complete the Data safety section, declaring the data types collected and shared, the purposes, whether each item is required or optional, whether data is encrypted in transit, and whether users can request deletion. Google requires it to be accurate and to reflect what the app actually does. That is the useful overlap with a pentest: dynamic testing observes what the app and its bundled SDKs genuinely transmit and store, which is how teams discover their declaration was wrong. It was rarely dishonest. It was usually an SDK nobody audited.
The Independent security review badge is a different programme with a hard gate. That badge in the Data safety section comes from the App Defense Alliance Mobile Application Security Assessment, which is based on OWASP MASVS and MASTG. At assurance level AL2 the evaluation must be performed by a Google Authorized Lab, which then issues a validation report to Google. Cybersecify is not an ADA Authorized Lab, so our report cannot produce that badge. If a vendor implies their standard pentest earns it, that is a claim worth checking against the Authorized Lab list.
Policy findings are a by-product, not the point. A pentest will surface things that also happen to be Play policy problems, such as an SDK collecting more than you declared or permissions requested well beyond what the app needs. That is useful. It is not a compliance review, and we do not sell it as one.
What evidence does an Android pentest give my SOC 2 or ISO 27001 auditor
An independent third-party test against a defined scope, with findings, severities, reproduction steps and verified remediation. That is what auditors take.
For ISO 27001:2022, the report supports A.8.8 management of technical vulnerabilities and A.8.29 security testing in development and acceptance. For SOC 2, it supports CC7.1 Vulnerability Detection, and where mobile authentication and authorization are in scope, CC6.1 Logical Access.
Two limits, stated plainly because they are the ones that cause trouble later.
A pentest report does not evidence a secure development lifecycle control. Auditors expect that shown through process: your design reviews, your code review gates, your release approvals. A vendor mapping a test report to a lifecycle control is stretching, and a good auditor will say so.
And Cybersecify is not a certification body. We are not CERT-In empanelled, and we are not ourselves SOC 2 or ISO 27001 certified. We produce the evidence and the control mapping; the certificate or attestation is issued by an accredited certification body or a licensed CPA firm. For how the evidence package fits together, penetration testing for SOC 2 covers the timing and format auditors expect, and ISO 27001 controls explained covers the Annex A side.
One scheduling note that costs people their audit window: book roughly 8 to 10 weeks before the audit. The testing is 5 or 10 business days. Your own remediation is the long pole, and the retest has to land inside the same evidence period.
How long does an Android app pentest take and what does it cost
The numbers are published rather than quoted case by case, on our pricing page.
- Startup Pentest, INR 74,999 plus taxes. One scope, 5 business days. The Android app alone.
- Growth Pentest, INR 1,79,999 plus taxes. Two scopes, 10 business days. Android plus iOS, or Android plus the API behind it.
Business days means Monday to Friday. The weekend is buffer, not counted testing time. Scopes run sequentially by default; running two in parallel is available on request, depends on tester availability when you book, and is not guaranteed, so do not build a customer deadline on the assumption.
Both plans include one free retest within one month of the v1.0 report. The retest runs 1 to 3 business days and produces a v2.0 report that supersedes v1.0, with updated status per finding and fresh proof for each fixed issue, which is what an auditor or an enterprise reviewer wants to see rather than an email saying the issues were closed.
Both founders are on every engagement. Rathnakara GN (OSCP, M.Sc Cyber Security) leads pentest delivery. For how we compare against other quotes you may be holding, pentest cost in India sets out the realistic range and what each tier actually contains, and manual pentest versus automated scanning covers why an APK scanner report is priced the way it is.
What do you need from us before an Android pentest starts
Access is what slips, not testing. Five things:
- A build we can install. A release or release-candidate APK or AAB matching what you actually ship. A debug build has different flags and different behaviour, and findings from it do not transfer cleanly to production.
- Test accounts, at least two per role, in separate tenants. Authorization boundaries can only be tested by actually crossing them, which needs two real accounts on either side of the boundary.
- The backend environment, named. Which API the build points at, and whether we are testing against staging or production. If it is staging, we need to know where it differs from production on authentication, authorization and rate limiting, because a staging copy with authentication stubbed out produces findings that do not transfer.
- Any attestation, anti-tamper or fraud tooling, disclosed upfront. We will trip it. Far better to agree that in advance than to have your on-call engineer paged at midnight over our traffic.
- About 30 minutes with an engineer who knows the app, to walk the flows that matter commercially rather than the ones that are easiest to find.
If you are scoping this for the first time, how to scope your first pentest walks the same ground for a general engagement.
When do I not need an Android app pentest
We would rather scope you correctly than sell a scope you do not need. Three cases where the honest answer is not yet.
Your app is a thin web view wrapper. No local storage, no offline mode, no native code, no platform integrations. Most of your real risk sits in the web application and the API, and testing those first is the better spend. The mobile scope can wait until the app does something genuinely native.
Nobody has asked, and the app handles nothing sensitive. No enterprise customer, no investor, no compliance programme, no regulated data. Then this is not the highest-value security work available to you this quarter.
Your backend has never been tested. Do that first. A server-side authorization flaw is exploitable by anyone with an HTTP client. A local storage finding generally requires physical access to an unlocked device or malware already on it. Fix the one with the wider blast radius first.
The case for the mobile scope gets strong quickly when any of these are true: the app stores data locally for offline use, it handles payments or financial data, it uses biometrics or device-bound authentication, a customer or auditor has explicitly asked, or you have anti-fraud requirements that depend on root detection meaning something.
What to do next
If you have a report already and want to know whether it covers your mobile build, send us the scope section. We will tell you what it covers and what it does not, no NDA needed and no follow-up unless you want one. That is a five-minute answer and it is usually the honest end of the conversation.
If you want to see the deliverable first, read the sample report and the methodology page, which set out the frameworks and how findings are scored and mapped. If you would rather talk it through, book a 30-minute scoping call with the founders.
Android application pentest | iOS application pentest | Pricing | Sample report | Methodology
Cybersecify is a Bengaluru-based founder-led cybersecurity consultancy serving AI-first and API-first SaaS startups. Both founders are on every engagement: Rathnakara GN leads pentest delivery, Ashok Kamat leads consulting and client work.