Runtime application self-protection monitors application behavior from inside the running application and can help detect or block suspicious activity in context.
Runtime application self-protection (RASP) is a security approach where an application monitors its own behavior while running and can help detect or block suspicious activity in context. In plain language, it brings some security decision-making inside the application instead of relying only on external scanning or filtering layers.
RASP matters because applications have direct awareness of their own code paths, requests, and execution context. That internal perspective can help identify suspicious behavior in ways that are difficult for purely external controls to see.
It also matters because organizations often want layered protection around live applications. Runtime-aware controls can complement secure coding, testing, and network filtering.
RASP appears in application-protection platforms, high-sensitivity web applications, API protection discussions, and defense-in-depth strategies for runtime services. Teams use it when they want more context-aware protection inside the running application in addition to Web Application Firewall, SAST, and DAST.
Security teams evaluate RASP when they want stronger runtime visibility into suspicious application behavior, but they still treat it as one layer rather than a substitute for fixing insecure code or unsafe design.
A sensitive API service uses runtime-aware protections that observe how requests interact with internal application logic. When a request pattern behaves inconsistently with expected execution paths, the service can flag or interrupt the behavior instead of relying only on a perimeter control to notice it.
| Control | Primary vantage point | What it adds |
|---|---|---|
| RASP | Inside the running app | Context-aware detection and response tied to code paths. |
| WAF | In front of the app | Request filtering without deep runtime context. |
| DAST | Outside, during testing | Finds behavioral issues in staging or production. |
Teams evaluate RASP by looking at runtime coverage, false-positive behavior, deployment impact, logging quality, and whether the control helps developers fix root causes instead of only blocking symptoms.
RASP output should feed normal security operations. A runtime block or alert is most useful when it includes the application route, user context, code path, and enough evidence for triage without exposing sensitive data in logs.
RASP is not the same as a Web Application Firewall. A WAF typically inspects traffic in front of the application, while RASP operates with direct application runtime context.
It is also not a replacement for Secure Coding. Runtime protection can help reduce exposure, but the underlying code still needs to be designed safely.