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.
What does RBI expect from mobile banking app security?
RBI expects mobile banking apps to be tested before release and periodically after, covering insecure local storage, certificate pinning, tamper and root detection, and the APIs behind the app — the OWASP Mobile Top 10 restated as control language. Macksofy delivers CERT-In-format mobile application penetration tests for Indian BFSI.
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: