Android RASP
Android RASP: protection that runs inside the app
What runtime application self-protection means on Android, what it detects and how to adopt it without breaking real users.
Short answer
RASP (runtime application self-protection) is code inside your app that checks, while the app runs, whether the device and the app itself can be trusted: root, emulators, debuggers, hooking frameworks and modified copies. A policy then decides the response, from just reporting to ending the session. It raises the cost of an attack; it does not make an app impossible to attack.
Why Android apps need it
An APK can be downloaded, unpacked, modified and installed again by anyone. On a rooted phone or with an instrumentation tool attached, an attacker can read memory, skip checks and change what the app sends. Rules on your server only see the requests that arrive, not the device that produced them.
What RASP checks
Typical checks look at the environment (root, emulator, unsafe device state), instrumentation (Frida, Xposed, hooked functions), debugging (an attached debugger, process tracing) and integrity (signature, modified code, re-signed copies). Each signal is weak alone; several together give a usable verdict.
How to roll it out safely
Start in monitor mode: the app reports what it would have done and blocks nothing. Look at the real events from your install base, then move each detection to warn, block or end the session, one at a time. Pair runtime checks with build hardening (obfuscation) so the checks themselves are harder to find and remove.
What the sources say
OWASP MASVS-RESILIENCE-1 asks that the app validates the integrity of the platform it runs on, and MASVS-RESILIENCE-4 that it implements anti-dynamic analysis techniques.
Source · checked on
Frida, a tool used to inspect and change apps while they run, describes itself as a dynamic code instrumentation toolkit.
Source · checked on
Google's Play Integrity API returns verdicts about the device, the app and the account, which a backend can check alongside the app's own signals.
Source · checked on
What Moatgator does
Runtime detects root, emulators, Frida, Xposed, debuggers and tampering inside the app.
Source · checked on
The response per detection lives in moatgator.yml: monitor, warn, block or end the session, and every detection starts in monitor mode.
Source · checked on
Shield obfuscates the compiled app in your pipeline and returns it unsigned, so your signing keys stay with you.
Source · checked on
The free plan includes five detections in monitor and warn modes.
Source · checked on
Where it stops
No single check is proof, and a determined attacker with time can bypass client-side checks. RASP buys signal and time; pair it with server-side verification (Attest or Play Integrity) for the actions that move money.
Frequently asked questions
Is RASP the same as obfuscation?
No. Obfuscation makes the code harder to read before it runs; RASP checks the environment while it runs. Use them together: obfuscation also hides the RASP checks.
Will RASP block legitimate users?
It can if you enforce too early. That is why detections should start in monitor mode, so you see real-world impact before blocking anything.
Do I need to change my source code?
With Moatgator, no. Protection is added to the compiled app in your build pipeline and the policy lives in moatgator.yml.
Does it work for iOS?
Moatgator supports Android and iOS (beta). This guide covers Android.
See where your app stands
Upload an APK, AAB or IPA to the free Scan and get a grade, without an account.