Runtime application self-protection (RASP) is a security technique that uses instrumentation inside a running application to detect and block attacks, using information from inside the software. Unlike a network firewall, it sees which function receives the input and what it does with it. It adds a layer; it does not fix the flaw.
How does RASP work?
RASP is built into or attached to the application, typically as a library, agent or module that runs alongside the program's code, libraries and system calls. It watches inputs and the application's own behavior, such as a database query being built or a file being opened, and decides whether the action looks like an attack.
The difference from perimeter controls is the point of view. A web application firewall or network firewall judges traffic using network and request information. RASP judges what happens inside, with context about the code path. That is why its proponents say it can distinguish a harmless string from one that actually reaches an interpreter.
What are its operating modes?
Common documentation describes two. In monitor mode, the tool reports attacks but does not block them. In protection mode, it reports and blocks. A sensible rollout starts in monitor mode, reviews what would have been blocked, and moves to protection once the false positive rate is acceptable.
How is it different from IAST and a firewall?
Interactive application security testing, IAST, also instruments the running application, but its goal is to find vulnerabilities during testing. RASP uses similar instrumentation for protection in production. A web application firewall sits in front of the application and inspects requests, with no view of the code.
The three answer different questions. IAST asks what is wrong with this code. A firewall asks whether this request looks bad. RASP asks whether this action inside the application looks bad.
What are its limits?
We could not find a standards body definition of RASP, and most descriptions come from the technique's vendors and trade press, so treat strong claims with care. Based on how the technique works, these are the things to test rather than assume.
It depends on language and framework support, since the instrumentation must hook the runtime. It adds work on the request path, so measure latency under your own load. It can block legitimate behavior, which is why monitor mode matters. And it protects the application at runtime only. The vulnerability remains in the code, and anyone who reaches it by a path the tool does not model may still succeed.
NIST's Secure Software Development Framework frames the broader point: find vulnerabilities before release through review, analysis and testing, record and triage each issue, and fix it. RASP belongs in the response toolkit for the time between disclosure and fix, or for software you cannot change quickly.
A constructed example
A team runs a legacy Java application that the vendor no longer updates. A deserialization flaw is announced for a library inside it. They cannot replace the library for several weeks. They attach a runtime agent in monitor mode, review a week of logs, confirm that the only flagged events are real exploit attempts and one internal health check, add an exception for the health check, and switch to protection. The attempts are now blocked while the team plans the library upgrade. They add the upgrade to the backlog with a date, and treat the agent as temporary cover.
How to check or apply this
- Confirm that your language and framework are supported, and test the agent in staging first.
- Run in monitor mode, and review every event before enabling blocking.
- Measure latency and resource use under production-like load.
- Define what happens on a block: alert, ticket, owner, and a way to roll back the agent.
- Keep the underlying fix on the backlog with a date.
- Combine RASP with dependency scanning and testing, so you find and remove the flaws it is covering.
Safeguard's reachability analysis helps decide whether a vulnerable library is actually called, which tells you how urgent a runtime workaround is. It does not provide RASP.
Quick check
Does RASP replace a web application firewall?
No. They sit at different points and see different things. Some teams use both, with the firewall filtering at the edge and RASP deciding inside the application.
Is RASP a substitute for patching?
No. It reduces exposure while a fix is prepared. The flaw is still in the code until you remove it.
Sources
- Wikipedia, Runtime application self-protection
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
