What is RASP? Runtime app protection and its limits
Runtime application self-protection helps mobile apps notice tampering and hostile devices. The attacks it targets, where it falls short, and what to ask a vendor.
On this page 13 sections
- Where the term comes from
- Why mobile apps are exposed
- The attacks RASP is meant to catch
- Modified and repackaged apps
- Debugging and hooking
- Rooted, jailbroken and emulated devices
- Risky conditions
- RASP vs WAFs vs obfuscation
- Where you'll see RASP
- The limits of RASP
- Questions to ask about any RASP solution
- Key takeaways
- Frequently asked questions
RASP, or runtime application self-protection, is security built into an app so that the app can tell, while it is running, that it is being tampered with, inspected or run on a hostile device, and respond. It matters most for apps that guard money or paid content, because a mobile app runs on a phone that its owner fully controls. RASP raises the cost of an attack; it doesn't make one impossible.
If you've ever seen a banking app refuse to open on a rooted phone, you've met RASP. This guide explains the attacks it is meant to catch, how it differs from firewalls and code obfuscation, where it falls short, and what to ask before you rely on it.
Where the term comes from
The analyst firm Gartner coined the term in 2012 for security that is built into, or linked to, an application and its runtime environment, so the application can detect and stop attacks while it's running. The idea first took hold on servers, where RASP agents sit inside web applications and block attacks such as SQL injection.
On mobile, the same idea often goes by names such as in-app protection or app shielding, and the threat is different. The app runs on a device the attacker may fully control, so the questions become: is the environment I'm running in trustworthy, and am I still the app I was built to be?
Why mobile apps are exposed
A web application runs on your servers, which you control. A mobile app runs on the user's phone, which you don't. Anyone can download your app, unpack it, study it, modify it and run it in an environment built for attacking it. For apps that protect money, identity or paid content, that's a real problem. Attackers typically want to:
- bypass checks, such as payment, licence or subscription checks;
- pull secrets, API details or content keys out of the app;
- switch off a protection, such as a block on screen recording;
- automate the app at scale for fraud or content scraping;
- distribute a modified copy of the app with its protections removed.
For a course app, each of these is a leak route. A modified app with recording protection switched off, or one running on an emulator, can turn one paid account into a supply of recorded lectures.
The attacks RASP is meant to catch
Modified and repackaged apps
Attackers take an app apart, change it, for example to remove a subscription check or a recording block, and put it back together. The modified copy is then shared outside the app stores, often promising free access to paid content.
Debugging and hooking
Attackers study a running app with debuggers, or use instrumentation tools to intercept its functions and change what they do. That lets them watch how the app handles secrets, or make a security check always report "all clear".
Rooted, jailbroken and emulated devices
Rooted Android phones and jailbroken iPhones remove protections the operating system normally enforces, letting other software inspect or alter your app. Emulators let attackers run many copies of an app on a computer and automate them. Tools that hide rooting are widely available, so a naive check is easy to fool. Our guide to root, jailbreak and emulator detection goes into this cat-and-mouse game.
Risky conditions
Some threats come from settings rather than tools: screen recording or mirroring, windows drawn on top of the app, USB debugging, or accessibility services that can read the screen. Whether each one matters depends on what the app protects.
RASP vs WAFs vs obfuscation
| Control | Where it runs | What it protects against | Blind spot |
|---|---|---|---|
| Web application firewall (WAF) | In front of your servers, inspecting incoming web traffic | Attacks on your servers and APIs, such as injection attempts and abusive bots | Can't see what happens inside the app on the user's device |
| Code obfuscation | Applied to the app when it's built | Static analysis: it makes the code hard to read and reverse-engineer | Doesn't notice or react to attacks while the app is running |
| RASP | Inside the app, while it runs | Tampering, debugging, hooking and hostile environments at runtime | Runs on a device the attacker controls, so it can be bypassed with enough effort |
These controls complement each other rather than compete. Android and iOS also offer integrity services of their own: Google's Play Integrity API, which replaced the older SafetyNet Attestation API, and Apple's App Attest, part of its DeviceCheck framework. They give an app's server a second opinion on whether it is talking to a genuine copy of the app on a genuine device.
Where you'll see RASP
Banking and payment apps are the most visible users. In India, the RBI's 2021 Master Direction on digital payment security controls suggests that regulated entities such as banks explore checking whether a phone is rooted or jailbroken before their app is installed, and stopping the app from installing or running if it is. Streaming and education apps use similar protections to guard paid video, games use them against cheating, and enterprise apps use them to protect company data on personal phones.
The limits of RASP
- It can be bypassed. The app runs on hardware the attacker controls, so a skilled, determined attacker can find and disable checks. RASP raises the cost of an attack; it doesn't make attacks impossible.
- It can't see outside the phone. A second phone filming the screen is invisible to any app protection, as is a login shared with friends who use their own genuine phones.
- False positives hurt real users. Some legitimate users run custom software or have rooted phones for harmless reasons. Blocking them all outright costs you customers.
- It's an arms race. Root-hiding and hooking techniques keep evolving, and each OS release changes the rules, so protections need regular updates.
- Privacy and app-store rules apply. Some detection techniques are restricted. Google Play, for example, treats a device's full list of installed apps as sensitive and limits which apps may query it.
- Performance matters. Poorly designed checks can slow app start-up or drain the battery on budget phones.
- It's no substitute for secure design. Important decisions, such as who may access what, still belong on the server.
Questions to ask about any RASP solution
- Which threats does it cover: modified and repackaged apps, debugging, hooking, rooting and jailbreaking, emulators, and screen capture?
- Can you choose how the app responds to each threat, and are detections reported to your server?
- How does it treat honest students with unusual phones, and how are false alarms explained to them?
- Does it work alongside Play Integrity and App Attest?
- What does it add to app size, start-up time and battery use on budget Android phones?
- How quickly is it updated for new OS versions and new bypass techniques?
- What data does it collect from devices, and does that fit your privacy policy, India's data protection rules and the app stores' policies?
Key takeaways
- RASP is security built into an app that notices and responds to attacks while the app runs.
- On mobile, it targets modified apps, debugging, hooking and hostile environments such as rooted phones and emulators.
- It complements, rather than replaces, WAFs, code obfuscation and platform integrity checks.
- It can be bypassed with enough effort, and it can't see a camera pointed at the screen or a shared login.
- Judge any RASP product on coverage, false positives, update speed and data practices.
VidSafe brings RASP to institutes' apps, alongside VidSafe proprietary encryption, screen- and camera-recording detection, account-sharing prevention, PDF watermarking, and visible and invisible watermarks that are extremely hard to remove. Institutes with their own apps can read about adding it in keep your LMS, secure your videos.
Frequently asked questions
What does RASP mean in mobile security?
RASP stands for runtime application self-protection. In mobile security it means protection built into the app itself, which checks while the app runs whether it has been modified, is being debugged or hooked, or is running on a rooted, jailbroken or emulated device, and responds, for example by refusing sensitive actions. It is also called in-app protection or app shielding.
What is the difference between RASP and a WAF?
A web application firewall sits in front of your servers and inspects incoming traffic for attacks such as injection attempts. RASP sits inside the app and watches what happens while the app runs, on a device you don't control. A WAF can't see a tampered app on a rooted phone, and RASP can't filter attacks on your servers, so many apps use both.
Can RASP be bypassed?
Yes, with enough skill and effort. The app runs on hardware the attacker controls, so checks can in principle be found and switched off. Good RASP makes that slow and expensive, and reporting detections to the server helps, because a server can act on suspicious signals even when a check on the phone has been defeated.
Does RASP stop screen recording?
Not by itself. RASP can notice some risky conditions, such as a modified app with its recording block removed, but whether recording can be blocked depends on the operating system. Android lets apps block recording of their own screens, while iPhone apps can only detect it. No app protection can see a second phone filming the screen; see iPhone screen recording detection for the limits.