RASP for Mobile SDKs: What Runtime Self-Protection Does and Does Not Solve
When an authentication SDK runs inside a bank’s app on a customer’s phone, the security boundary is no longer the server. The app, its memory, and the device it runs on are all under someone else’s control. Runtime application self-protection (RASP) is one response to that problem.
What RASP Is For
OWASP’s Mobile Application Security Testing Guide treats RASP as a technology embedded in the app to detect and respond to attacks while the app runs. It sits under the resilience requirements in MASVS-RESILIENCE, next to obfuscation and tamper resistance.
The useful question is not “does RASP stop attacks?” It is “does RASP make attacks expensive and visible enough to matter?”
The Categories
At the level of principle, mobile RASP covers four groups:
- Attached tools. Debuggers and instrumentation frameworks that observe or change app behaviour.
- Modified code. Repackaged or patched binaries, and integrity failures in the app’s own code.
- Hostile environments. Rooted or jailbroken devices, emulators, and other conditions the app’s risk model does not trust.
- Runtime manipulation. Hooking that redirects calls the app depends on.
These are categories, not a recipe. Publishing specific checks, their thresholds, or the order they run would help an attacker more than it helps a defender.
Why It Is Bypassable
Anything the app checks, an attacker with control of the device can also observe. The check itself runs on hardware the attacker owns. OWASP’s guidance on RASP signals is direct about this: these controls are not a replacement for secure design, and they should be tuned to the app’s threat model.
Two design consequences follow:
- Treat RASP output as a signal, not a verdict. A detection is evidence for the server to weigh, combined with other facts about the session.
- Keep the sensitive decision on the server. If a bypass lets the client believe a check passed, the server should still refuse an operation it cannot verify.
Where It Fits
A layered design for a mobile SDK looks roughly like this, from outside in:
- Secure design that assumes the client is untrusted.
- Obfuscation and hardening of the binary, which raises the cost of reading it.
- RASP signals from the runtime, which raise the cost of changing it.
- Server-side verification of every sensitive decision.
- Device attestation where the platform supports it.
Each layer assumes the one outside it can fail. No single control is treated as sufficient.
Practical Notes for SDK Teams
- Ship protections inside the SDK once, rather than asking each integrating app to build its own. Integrators will not all get it right.
- Pick secure defaults. An integrator who never reads the documentation should still get a safe result.
- Test against the attacks you expect, including instrumentation, on every platform you ship. A control that works on one platform often has a different weak point on another.
- Be honest about what the layer does not do. A RASP signal does not prove the device is clean.
RASP is worth having, but as one part of a design that does not depend on it.
Continue Reading
Firmware Upgrade Trust on Android: Signing, Rollback, and Post-Update Checks
An over-the-air firmware update is only as trustworthy as the checks around it. This post walks through the trust chain from delivery to post-update validation, and how it ties to device attestation.
Securing AI Pipelines: Threat Modeling for LLM and Agentic Systems
An engineering-level threat modeling analysis of security vulnerabilities in Large Language Model (LLM) integration, Retrieval-Augmented Generation (RAG) pipelines, and autonomous AI agents, with practical architectural mitigations.