
Mobile App Security for Indian BFSI
RBI Mobile Cyber Security Framework expectations, the OWASP Mobile Top 10 — translated for Indian banks and NBFCs — and a secure-SDLC integration model.
Indian BFSI mobile apps face a tighter scrutiny than most: RBI's Mobile Cyber Security Framework, BBPS / NPCI integration audits, and a customer base that loses trust quickly. This whitepaper distils what we see across mobile pentests for tier-1 banks, listed NBFCs and fintechs.
1. RBI's mobile expectations, in plain language
RBI's mobile guidance — combined with the Master Direction on Digital Payment Security — sets the floor: device-binding, secure storage, runtime protections, transaction-signing, and tamper detection. Most banks meet four of those five; the fifth (tamper detection) is where pentests routinely surface findings.
2. OWASP Mobile Top 10, translated for BFSI
| OWASP risk | BFSI failure mode | Auditor question |
|---|---|---|
| M1 Improper credential use | API keys / tokens in shared_prefs / Keychain | Show me your secret-storage architecture. |
| M2 Inadequate supply chain | SDKs that exfiltrate device data | List every SDK + its data-collection scope. |
| M3 Insecure auth/auth | Account takeover via deeplink | Walk me through deeplink validation. |
| M4 Insufficient I/O validation | JWT alg=none accepted | Show JWT validation tests. |
| M5 Insecure communication | Cert-pinning bypass via debug builds | Demonstrate pinning under MITM. |
| M6 Privacy controls | Logging PAN / Aadhaar to system log | Audit your log-redaction layer. |
| M7 Insufficient binary protections | No tamper detection / no anti-debug | What happens to a re-signed app? |
| M8 Security misconfiguration | Backup flag enabled on production | Show your manifest hardening. |
| M9 Insecure data storage | Cleartext database files | Where do you store offline data? |
| M10 Insufficient cryptography | Hard-coded encryption keys | Demonstrate key derivation. |
3. Secure-SDLC integration without killing velocity
Mobile teams that integrate security at release-cycle granularity outperform teams that bolt it on annually. The pattern that scales:
- MASVS-driven static analysis on every commit (free or commercial — both work)
- Quarterly external mobile pentest covering iOS + Android + backend APIs
- Annual deep red-team-grade engagement with binary-protection bypass attempts
- Block-on-build CI gates for hard-coded secrets, weak crypto, and insecure manifest flags
We bypass cert-pinning in 90%+ of mobile pentests in under an hour. Pinning slows down the script kiddie; it does not stop a real adversary or even a determined penetration tester. Treat pinning as one layer, never the only layer.
4. Five things to demand from your mobile pentest provider
- Manual exploitation, not just MobSF outputTooling-only reports miss authorization, deeplink and session-handling logic flaws.
- Both iOS and Android in scopeFindings on one platform almost always have analogues on the other.
- Backend API in the same engagementMobile pentest without API depth misses 60% of the customer-impact findings.
- Free retest within 30 daysStandard at Macksofy; treat this as a baseline expectation across vendors.
- OSCP / OSWE-certified operators on the engagementVerify the assigned consultant's certs before signing the SOW.
Macksofy offers full-service engagements that map directly to this resource. Common starting points:
