Mobile App Security Testing: OWASP MASVS for Indian Fintech

Mobile app security testing is the structured process of finding and fixing vulnerabilities in Android and iOS applications before attackers exploit them. For Indian fintech — UPI payment apps, lending platforms, wealth management tools, and insurance aggregators — this is not optional. India processes over 13 billion UPI transactions monthly, making every fintech app a high-value target. The OWASP Mobile Application Security Verification Standard (MASVS) and its companion Mobile Application Security Testing Guide (MASTG) provide the most comprehensive, globally recognised framework for assessing these risks. This article explains what MASVS covers, the most common vulnerabilities found in Indian apps, and how a structured VAPT engagement works.

Why Indian Fintech Apps Are Prime Targets

The explosion of digital payments post-demonetisation created an enormous surface area. Android dominates with over 95% market share in India, and the majority of UPI-enabled apps are distributed outside the Play Store — through direct APK downloads, device pre-installs, and third-party marketplaces. This means standard Play Protect controls often do not apply.

Attackers targeting Indian fintech apps seek session tokens, stored OTPs, hardcoded API keys, and the ability to intercept payment flows. RBI's Master Directions on Digital Payment Security Controls mandate that regulated entities implement specific mobile security controls — including certificate pinning, jailbreak/root detection, and secure local storage. SEBI similarly requires that trading and investment platforms maintain data confidentiality at the application layer. Non-compliance is not merely a technical gap; it is a regulatory exposure.

13B+UPI transactions processed per month in India (NPCI 2025)

95%Android's share of the Indian smartphone market (Statcounter 2025)

What Is OWASP MASVS?

The OWASP Mobile Application Security Verification Standard is a framework that defines security requirements across eight control groups. It replaced the older numbered tier system (L1/L2/R) with a simplified category-first model. The companion MASTG provides test cases, tooling, and procedures for each requirement.

The eight control groups are:

Control Group	What It Covers
MASVS-STORAGE	Sensitive data at rest — local DB, SharedPreferences, Keychain/Keystore
MASVS-CRYPTO	Algorithm choices, key management, random number generation
MASVS-AUTH	Authentication, session management, biometric integration
MASVS-NETWORK	TLS configuration, certificate pinning, traffic interception
MASVS-PLATFORM	Intent handling, exported components, WebView security, IPC
MASVS-CODE	Code quality, third-party libraries, anti-debugging controls
MASVS-RESILIENCE	Root/jailbreak detection, emulator detection, anti-tampering
MASVS-PRIVACY	Data minimisation, consent, analytics data leakage

Each control group contains individual requirements. A VAPT engagement scopes which requirements apply — a basic payment SDK needs STORAGE, CRYPTO, AUTH, and NETWORK at minimum; a trading app with biometric login needs all eight.

🛡️

SECURITY

MASVS-RESILIENCE controls are often skipped by Indian developers because they appear optional. For regulated fintech apps handling payments or securities, they are baseline requirements under RBI and SEBI guidelines — not aspirational hardening.

OWASP Mobile Top 10 — What Keeps Appearing in Indian Apps

The OWASP Mobile Top 10 distils the most frequently exploited vulnerability categories. In Indian fintech specifically, the following appear most consistently:

M1 — Improper Credential Usage: Hardcoding API keys, payment gateway tokens, or internal service credentials directly in the app binary. These are trivially extracted by decompiling an APK with apktool or jadx. Multiple Indian fintech apps found in public research have exposed AWS keys, Razorpay webhook secrets, and Firebase credentials this way.

M2 — Inadequate Supply Chain Security: Third-party SDKs — analytics, crash reporting, attribution — often collect more data than the first-party app discloses. Some Indian apps bundle SDKs that maintain persistent device identifiers or phone number hashes, creating regulatory exposure under DPDP Act 2023.

M3 — Insecure Authentication/Authorization: OTP-based flows where the OTP is also stored locally or transmitted in a predictable parameter; sessions that do not expire; refresh tokens stored in plaintext SharedPreferences.

M4 — Insufficient Input and Output Validation: SQL injection into local SQLite databases; JavaScript injection through insecure WebViews with addJavascriptInterface exposed to untrusted content.

M5 — Insecure Communication: Self-signed certificates accepted without validation; SSL pinning disabled in production builds because developers found it inconvenient to update; HTTP fallback allowed for certain endpoints.

M8 — Security Misconfiguration: Android manifest with android:exported="true" on Activities, Services, and BroadcastReceivers that should be internal — allowing any app on the device to trigger payment flows or read account data.

M9 — Insecure Data Storage: Sensitive user data written to external storage (SD card), unprotected SQLite databases, or logs/ directories. SharedPreferences stored without encryption. Room databases with no EncryptedSharedPreferences or SQLCipher.

⚠️

WARNING

Exported Android components are particularly dangerous on Indian devices where multiple fintech apps coexist. A banking app with an exported Activity can be triggered silently by a malicious companion app to initiate transfers or expose account state — no user interaction required.

Know your vulnerabilities before attackers do

Run a free VAPT scan — takes 5 minutes, no signup required.

Book Your Free Scan

Mobile App Security Testing: Static vs Dynamic Analysis

Mobile security testing uses two complementary approaches.

Static Analysis (SAST) examines the app without running it. For Android, the APK is decompiled and the Dalvik bytecode converted to Java or Smali. Testers look for:

Hardcoded secrets using string extraction and regex patterns
Dangerous permissions declared in the manifest
Exported components without intent-filter restrictions
Weak cryptographic APIs (MD5, SHA1, ECB mode, DES)
Insecure logging with Log.d calls containing PII or tokens

For iOS, the IPA is decrypted (on jailbroken devices) and analysed with tools like class-dump and MobSF.

Dynamic Analysis (DAST) runs the app in a controlled environment and observes its behaviour:

Traffic interception using Burp Suite or mitmproxy with certificate installed as a trusted CA
Bypassing certificate pinning using Frida hooks or objection
Runtime manipulation of authentication checks
Filesystem inspection post-login to find sensitive data written at rest
Testing deep links and IPC channels for parameter injection

graph TD A[APK / IPA Acquisition] --> B[Static Analysis] B --> C[Decompile and String Extraction] B --> D[Manifest and Permission Review] B --> E[Code Pattern Matching] C --> F[Dynamic Analysis] D --> F E --> F F --> G[Network Traffic Interception] F --> H[Runtime Hooking via Frida] G --> I[Certificate Pinning Bypass Attempt] H --> J[Auth and Session Manipulation] I --> K[Resilience and Anti-Tamper Checks] J --> K K --> L[Findings Consolidated] L --> M[Remediation Guidance] M --> N[Re-test and Verify] style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style F fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style G fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style H fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style I fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0 style J fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0 style K fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0 style L fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style M fill:#1e3d2f,stroke:#10B981,color:#e2e8f0 style N fill:#1e3d2f,stroke:#10B981,color:#e2e8f0

Common Pitfalls Specific to Indian App Development

Several patterns appear repeatedly in Indian fintech app codebases:

Hardcoded Firebase or Payment Gateway Keys: Development keys left in production builds, or a single key used across environments. Attackers extract these and access backend services directly, bypassing all app-level controls.

Plaintext Local Storage: SharedPreferences files containing UPI VPA (Virtual Payment Address), mobile number, or device identifiers in plaintext. These are readable by any app with root access on a rooted device — which is far more common in India than Western markets.

Weak or Absent Certificate Pinning: Many apps implement certificate pinning in debug builds but remove it before release because QA environments use self-signed certificates. The production build then accepts any valid CA-signed certificate, making MitM attacks trivial on corporate or shared Wi-Fi networks.

Overly Broad Manifest Permissions: Requesting READ_CALL_LOG, READ_SMS, and READ_CONTACTS well beyond what the app needs, often inherited from third-party SDKs. RBI's guidelines on digital lending apps specifically prohibit this.

Root Detection That Is Easily Bypassed: Checking for the presence of su binary or known root management apps is bypassed in minutes with Magisk or Frida. Effective root detection requires multiple layered checks, integrity attestation, and runtime anomaly detection — not a single boolean gate.

💡

TIP

If your Android app's root detection can be bypassed by running objection explore --startup-command "android root disable" in under 30 seconds, it is not security — it is theatre. Proper resilience uses Play Integrity API attestation backed by server-side validation.

RBI and SEBI Regulatory Relevance

The RBI Master Directions on Digital Payment Security Controls (DPSC Directions, 2021) require payment system operators to:

Implement application-layer security controls validated annually
Ensure sensitive data is not stored on device unless encrypted with hardware-backed keys
Conduct periodic vulnerability assessment of mobile applications

The RBI's Information Technology Framework for NBFC Sector and SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF) for regulated intermediaries extend these requirements to NBFCs, brokers, and AMCs. Mobile apps that access securities accounts or facilitate payments must demonstrate compliance through documented security testing.

CERT-In guidelines under the IT Act require incident reporting within six hours of discovery of material breaches — including those originating from mobile app vulnerabilities. Engaging a VAPT with a CERT-In empanelled partner generates the documentary evidence regulators expect during audits.

How Mobile VAPT Fits Into a VAPT Engagement

A mobile application VAPT is distinct from a web or network VAPT. It requires:

Test APK/IPA with source access if possible — source-assisted testing finds more than black-box
Backend API scope included — the app is only as secure as the APIs it calls
Environment with rooted/jailbroken device or emulator — necessary for dynamic analysis
Defined threat model — shared public app vs. internal enterprise app have different risk profiles

The deliverable is a structured report mapping each finding to the relevant MASVS control, OWASP Mobile Top 10 category, severity (Critical/High/Medium/Low), and a reproduction procedure. Remediation guidance is specific — not generic.

pie title Mobile App Findings Distribution by Category "Insecure Data Storage" : 30 "Insufficient Network Security" : 25 "Auth and Session Weaknesses" : 20 "Platform Misconfiguration" : 15 "Code Quality Issues" : 10

Bachao.AI's automated VAPT platform includes API and network-layer scanning that surfaces the backend vulnerabilities exposed by mobile apps — the insecure endpoints, over-privileged tokens, and unauthenticated routes that mobile VAPT static analysis flags as risks. Start with a free VAPT scan to see your current exposure before a full mobile engagement.

🎯Key Takeaway

Mobile app security for Indian fintech is not a checkbox exercise. OWASP MASVS gives you a structured control catalogue; MASTG gives you the test procedures. The vulnerabilities that cause real harm — hardcoded keys, plaintext storage, exported components, pinning bypass — are all findable with a rigorous VAPT. Regulated entities under RBI and SEBI cannot treat this as optional: the audit trail starts with a documented security assessment.

What to Do Before Commissioning a Mobile VAPT

Before engaging a testing team, prepare the following:

Threat model document: Who is the attacker? Malicious co-installed app, MitM on same network, or physical device access?
Latest test build (APK/IPA): Release-equivalent build with obfuscation enabled, not a debug build
API documentation: All endpoints the app calls, including third-party SDKs
Backend access: Read-only staging environment credentials so API findings can be verified end-to-end
Previous test reports: If any exist — retesting residual findings costs less than finding them fresh

A well-scoped mobile VAPT takes between three and seven days depending on app complexity. The output should be actionable within a single sprint cycle.

Dhisattva AI Pvt Ltd builds the infrastructure that makes this testing systematic, repeatable, and audit-ready for Indian regulated entities.

Frequently Asked Questions

What is OWASP MASVS and why does it matter for Indian fintech apps?

OWASP MASVS is the Mobile Application Security Verification Standard — an open framework defining security requirements across eight control groups including storage, cryptography, authentication, network security, and anti-tampering. It matters for Indian fintech because RBI and SEBI security guidelines align closely with MASVS controls, and auditors increasingly expect MASVS-mapped findings in VAPT reports.

What is the difference between static and dynamic mobile app analysis?

Static analysis examines the app binary without running it — decompiling the APK to find hardcoded secrets, dangerous permissions, and insecure code patterns. Dynamic analysis runs the app in a controlled environment and observes real behaviour — intercepting network traffic, hooking runtime functions, and testing authentication flows. A complete assessment requires both; static alone misses runtime logic flaws, and dynamic alone misses what is embedded in the binary.

Are Indian Android apps more vulnerable than iOS apps?

Android's open ecosystem means APKs are more easily obtained, decompiled, and analysed than iOS IPAs. Root detection bypass is also more mature and accessible on Android. That said, iOS apps are not immune — certificate pinning bypass, insecure Keychain usage, and WebView XSS are common iOS findings. The risk profile differs; neither platform is inherently safe without deliberate security engineering.

Does RBI require mobile app penetration testing for regulated entities?

RBI's Digital Payment Security Controls Directions (2021) require payment system operators to conduct periodic vulnerability assessments of their mobile applications and maintain audit evidence. While the specific term "penetration testing" varies by circular, the intent is clear: annual application security testing is an expectation for entities handling payment data.

What is certificate pinning and why do Indian apps often get it wrong?

Certificate pinning makes the app accept only specific certificates or public keys for its backend connections, preventing traffic interception even when an attacker installs a rogue CA. Indian apps frequently implement it incorrectly by pinning only in debug builds, using expired pins without a backup pin, or allowing pinning to be disabled via a remote flag. Correct implementation requires backup pins, a rotation strategy, and server-side validation that pinning cannot be bypassed at runtime.

How long does a mobile app VAPT take and what does the output look like?

A thorough MASVS-aligned mobile VAPT takes three to seven business days for a typical fintech app, depending on complexity and whether API backend testing is in scope. The output is a structured report with each finding mapped to a MASVS control and OWASP Mobile Top 10 category, a severity rating, a reproduction procedure, and specific remediation guidance. Regulated entities should request that findings also reference the applicable RBI or SEBI control for audit purposes.