What Is RASP? Runtime Application Self-Protection for Mobile Apps

RASP, or runtime application self-protection, is security that runs inside the application while the application runs. Rather than inspecting traffic at a perimeter or scanning code before release, it gives the app the ability to observe its own execution environment and react to what it finds.

On mobile that capability is not a refinement. It is the only control physically present on the device at the moment an attack takes place.

Where RASP Sits

Three categories are routinely confused, and the distinction is simple.

The third row covers a case the first two cannot. Your app can be free of vulnerabilities and fully obfuscated, and still be running on a rooted device with a hooking framework attached to its process.

What RASP Detects on Mobile

Server-side RASP watches for malicious input. Mobile RASP watches the environment, because on a device the environment is the attack.

Compromised operating system. Rooting and jailbreaking remove the sandbox every other protection assumes.

Instrumentation. Hooking frameworks, injected libraries and attached debuggers, which are the mechanism behind most runtime tampering and every certificate pinning bypass.

Virtualisation and emulation. Containers that run your app inside another app, and emulators used for automated fraud at scale.

Integrity failure. A signature that no longer matches, indicating a repackaged build.

Screen and input interference. Overlays drawn above your views, screen recording during sensitive operations, and accessibility services reading or driving the app.

Why RASP Handles Threats It Has Never Seen

This is the property that matters most in evaluation.

Signature detection recognises named malware families and cannot recognise the variant released this morning. RASP identifies techniques instead. A tool built by an actor nobody has named still has to hook a function, inject a library, attach a debugger or re-sign a binary in order to work.

Those actions are observable regardless of what the tool is called, which is why runtime protection holds against attacks that did not exist when the policy was written.

The Two Questions That Separate Implementations

Does it work offline? Protection that verifies itself against a server can be defeated by blocking the server. On-device enforcement continues when the network does not.

Who sets the response? A blanket rule that ends the session on any detection produces support tickets, and support tickets get controls switched off. Policy set per threat and per app by you is what keeps RASP running past its second quarter.

RASP and Regulation

Runtime detection requirements now appear across BNM’s RMiT, the MAS Technology Risk Management Guidelines, HKMA supervisory guidance and the BSP circulars, usually expressed as an expectation that apps detect compromised device environments and log what they find.

Examiners increasingly ask two follow-up questions: what do you detect besides rooted devices, and what does the app do when it fires.

Where SecIron Fits

Related reading: Mobile App Hardening vs RASP vs App Shielding and What Is Mobile App Hardening?

Conclusion

RASP is best understood by what it assumes. Every other control assumes the app runs in a reasonable environment. RASP assumes it does not, and gives the app the ability to find out.

On hardware you do not own, patch or scan, that assumption is the correct one.

Ready to launch a secure app?

Bring us your app and a compromised device, and we will show you what runtime protection detects and what it does about it.

Contact us