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.

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:

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.

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:

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

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

1. Traffic interception using Burp Suite or mitmproxy with certificate installed as a trusted CA
2. Bypassing certificate pinning using Frida hooks or objection
3. Runtime manipulation of authentication checks
4. Filesystem inspection post-login to find sensitive data written at rest
5. 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.

RBI and SEBI Regulatory Relevance

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

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

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:

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

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.

What to Do Before Commissioning a Mobile VAPT

Before engaging a testing team, prepare the following:

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

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