Runtime application self-protection (RASP) is security logic built into an application that watches the application’s own execution and reacts when that execution is being observed or altered. On mobile it runs inside your app’s process on the user’s phone, a device the attacker may control. Evaluate it by the flows it guards, the split of work between app, operating system and server, and evidence gathered on physical Android and iOS devices. RASP makes attacks on a running app slower and costlier and produces a signal; it does not correct insecure server logic. Otukan builds RASP into Android, iOS, Flutter and React Native apps.
The threat and the trust boundary
A mobile app cannot trust the device it runs on. The boundary RASP defends is the app process itself: its memory, its code and the calls it makes. Attackers cross it by attaching tools that read or change the app while it runs.
| Runtime condition | What it lets an attacker do | Flow most at risk |
|---|---|---|
| Instrumentation or hooking | Change a function’s result, such as a failed check turning into a pass | Sign-in, licence and entitlement checks |
| Attached debugger | Step through logic and read keys from memory | Code that handles tokens or keys |
| Rooted Android or jailbroken iOS | Read the app’s private storage and lift the limits the sandbox enforces | Stored credentials, offline data |
| Emulator | Run many scripted sessions without real hardware | Account creation, promotions, in-game economy |
| Modified binary | Ship a copy with checks removed or ads injected | Every flow, through a fake distribution channel |
Control fit
The term began with server-side web applications. On mobile, three parties share the work.
- The app detects the conditions above and applies an immediate response: record, warn the user, restrict the flow or end the session.
- The operating system provides the sandbox and code signing. Android and iOS enforce them differently, and root detection on Android and jailbreak detection on iOS need separate checks.
- The backend receives the runtime signal with each sensitive request and decides whether to serve it. A decision made there is out of the attacker’s reach.
Static protection completes the picture: obfuscation and integrity checks keep the runtime logic hard to find and patch.
Evaluation
Test each point on your own builds and devices.
- Platform scope. Confirm each check separately for Android and iOS, and for the frameworks you ship.
- Check placement. Confirm checks run at start-up, before sign-in and before the actions you mark sensitive.
- Response per flow. Set a different response for browsing and for payment, and watch both.
- Backend signal. Trigger each condition on a test device and confirm your server receives it.
- User impact. Run clean devices, Android developer options and assistive tools, and measure launch time before and after.
How Otukan applies RASP
Otukan builds runtime self-protection into Android, iOS, Flutter and React Native apps. It detects hooking, debuggers, emulators, rooted Android and jailbroken iOS devices and modified copies, runs its checks at start-up, before sign-in and before the actions you select, applies the response you set for each flow and sends the signal to your backend. Obfuscation and integrity checks protect the checks themselves, and your signing keys stay with you.
The product is covered on mobile RASP, and the Apple-specific view is on iOS RASP. For how RASP relates to static protection, see app shielding vs RASP. Other terms buyers meet are defined in the mobile security glossary.