Mobile banking app security: what is RASP and what banks need

What is RASP in mobile app security?

RASP is protection embedded in the app itself. It watches for a compromised device, a modified app, an attached debugger or a hostile network while the app runs, then blocks, limits or reports the session.

A mobile banking app runs on a device the bank doesn't control. The phone may be rooted, infected with malware or on an attacker's Wi-Fi, and the app package can be decompiled and altered. Server-side controls can't see this, so RASP moves some checks into the app itself.

The OWASP Mobile Application Security Verification Standard (MASVS) covers this in its MASVS-RESILIENCE group: "Defense-in-depth measures such as code obfuscation, anti-debugging, anti-tampering, and runtime application self-protection (RASP) can increase an app's resilience against reverse engineering and specific client-side attacks." ^[1] Its four controls require that the app validates the integrity of the platform, implements anti-tampering mechanisms, and resists static analysis and dynamic analysis ^[1].

OWASP also cautions that the absence of these measures "does not in itself constitute a vulnerability", and that all apps must still meet the rest of the MASVS ^[1]. RASP adds to secure design and server-side validation; it doesn't replace them.

How is RASP different from app shielding, obfuscation and a WAF?

Obfuscation makes app code hard to read, app shielding usually bundles obfuscation with anti-tampering and RASP checks, RASP reacts to threats at runtime, and a WAF filters traffic at the server. They protect different places and work best together.

Which OWASP Mobile Top 10 risks matter most for banking apps?

All ten apply, but for banking apps the ones most directly addressed by app-side controls are insecure communication (M5), insufficient binary protections (M7), insecure data storage (M9), insufficient cryptography (M10) and insecure authentication (M3).

The OWASP Mobile Top 10 2024 (final release) lists M1 Improper Credential Usage, M2 Inadequate Supply Chain Security, M3 Insecure Authentication/Authorization, M4 Insufficient Input/Output Validation, M5 Insecure Communication, M6 Inadequate Privacy Controls, M7 Insufficient Binary Protections, M8 Security Misconfiguration, M9 Insecure Data Storage and M10 Insufficient Cryptography ^[2]. The mapping below shows typical controls. It is a practical guide, not an OWASP mapping.

What are root detection, SSL pinning, device binding, MITM and replay protection?

Root and jailbreak detection checks whether the phone's security model has been broken. SSL pinning makes the app trust only the bank's own certificates. Device binding ties an account to a registered phone. MITM and replay protection stop intercepted traffic from being read, altered or reused.

• Root and jailbreak detection: rooting (Android) or jailbreaking (iOS) removes the operating system's sandbox, so malware can read another app's memory or files. The app checks for signs of this and can refuse to run or restrict high-risk functions.
• SSL or certificate pinning: by default, an app trusts any certificate signed by an authority the device trusts, including one an attacker has installed. Pinning limits trust to the bank's expected certificate or public key, so an intercepting proxy is rejected.
• Device binding: the customer's account is linked to a specific registered device, often using a combination of hardware, software and SIM or service identifiers. A stolen password is then not enough on another phone.
• Man-in-the-middle (MITM) attacks: an attacker sits between the app and the server, for example on a rogue Wi-Fi hotspot, to read or change traffic. Pinning, end-to-end encryption and network checks are the usual defences.
• Replay attacks: an attacker captures a valid request, such as a payment instruction, and sends it again. Nonces, timestamps and request signing make each request valid only once.

What do RBI's Digital Payment Security Controls Directions say about mobile apps?

RBI's Digital Payment Security Controls rules set mobile app controls including mandatory device binding, device policy checks, phasing out old app versions and code obfuscation, while root and jailbreak checks are optional. Since 31 July 2026 they are issued as separate Directions for each type of regulated entity.

The 2021 Master Direction on Digital Payment Security Controls (RBI/2020-21/74) covered scheduled commercial banks (excluding RRBs), small finance banks, payments banks and credit card issuing NBFCs. On 31 July 2026 RBI issued separate Digital Payment Security Controls Directions for individual categories of regulated entity, for example small finance banks ^[3] and urban co-operative banks ^[4], repealing the earlier instructions for those categories. Each bank should read the Directions issued for its own category. The mobile application controls in the SFB and UCB Directions include the following ^[3][4]:

• The bank shall enforce a device policy that allows the app to install or run only after baseline checks, including for a vulnerable operating system, vulnerable or malicious apps and insecure Wi-Fi configurations.
• The bank shall deactivate older app versions in a phased but time-bound manner, within six months of releasing a newer version, and shall identify remote access applications where possible and prohibit login from them.
• Other listed controls include secure download and installation, device or application encryption, minimal data collection and app permissions, application sandboxing and code obfuscation.
• The bank shall ensure device binding of the mobile application, implemented through a combination of hardware, software and service information. If several devices may be registered, the user must be notified of each new device.
• The bank may explore checking whether the device is rooted or jailbroken before installation and disallowing the app from installing or functioning on such a device. This check is optional, not mandatory.
• The bank shall host the checksum of the current app version on a public platform so users can verify it.
• The app should require re-authentication each time it is launched and after an idle period, and should not store user IDs, passwords, keys or hashes on the device.

This guide summarises regulation and standards for general information and is not legal or compliance advice. Always refer to the current text of the RBI Directions for your category of institution, and note that some controls are stated as mandatory ("shall") while others are advisory ("may").

What should banks check when evaluating a mobile app security or RASP solution?

Check which threats it detects, what it does when it detects them, how it protects network traffic, storage and authentication, how it is integrated and updated, and how its controls map to OWASP MASVS and your regulator's requirements.

• Detection coverage: root, jailbreak, emulators, debuggers, hooking, app tampering, repackaging, malware and remote access tools.
• Response options: block, restrict features, force re-authentication or alert the server, and whether the bank configures these per threat.
• Network protection: certificate pinning, detection of compromised or unsecured Wi-Fi, and MITM and replay defences.
• Data protection: encrypted local storage, secure key handling and no sensitive data left on the device.
• Authentication support: device binding, session handling and cryptographic protection of credentials.
• Binary hardening: obfuscation and anti-tampering on both Android and iOS builds.
• Standards mapping: evidence against MASVS-RESILIENCE and the other MASVS groups, and against the RBI Direction clauses that apply to you.
• Operational fit: effect on app size, start-up time and false positives, and how quickly new bypass techniques are addressed.

Where does LCode's D-Secure fit?

D-Secure is LCode Technologies' mobile app security suite for banking apps. It provides protection across five layers: application binary, network connectivity, transport, application authentication and storage.

About LCode: this section describes LCode Technologies' own product. The table lists what D-Secure includes in each layer.

Frequently asked questions