What Is RASP? Runtime Application Self-Protection

A web application firewall sees an HTTP request with ' OR 1=1 -- in a parameter and has to guess whether it is an attack. It does not know if that string ever reaches a database, what query it lands in, or whether the code already parameterized it into harmlessness. It pattern-matches at the perimeter and either blocks legitimate traffic or misses the obfuscated payload it did not have a signature for. Runtime Application Self-Protection (RASP) removes the guessing. It sits inside the running application, watches the actual database call that the request produces, and decides based on what the code is about to do, not what the traffic looks like from outside.

RASP is a security technology built into an application or its runtime environment that detects and blocks attacks in real time, using the application's own execution context to make the call. It does not scan code before deployment and it does not filter traffic at the edge. It instruments the running application, hooks its sensitive operations, such as database queries, file access, and system commands, and evaluates each one against the data and control flow that produced it. When an operation is malicious, RASP terminates it.

This guide covers what RASP is and where the term came from, how the instrumentation actually works, its monitoring and blocking modes, how it differs from a web application firewall, what it is good at and where it falls short, and where it fits a DevSecOps program. It is written for defenders: SOC analysts, AppSec engineers, and DFIR responders who have to reason about what a control can and cannot see.

What is runtime application self-protection (RASP)?

Runtime application self-protection is a security technology that is built or linked into an application, or its runtime environment, and is capable of monitoring application execution and detecting and blocking attacks in real time. Gartner analyst Joseph Feiman coined the term in 2012 to name an emerging category: tools that make an application capable of protecting itself from the inside, rather than relying on a separate device at the network edge.

The defining property is context. A perimeter control inspects traffic; RASP inspects behavior. Because it runs inside the application process, it has visibility a network device cannot get: the actual query string sent to the database, the file path an operation is about to open, the system command about to execute, the user and session behind the request, and the code path that connects the input to the dangerous operation. That visibility is what lets RASP distinguish a real SQL injection that reaches a query from a benign string that happens to look like one.

RASP is part of the broader application security discipline, but it occupies a specific slot in it. Static and dynamic testing find flaws before release. RASP protects the application after release, in production, while it runs. It is a runtime control, not a testing tool, and that is the distinction that places it.

How RASP works: instrumentation and runtime context

RASP works by instrumenting the application from the inside. Instead of scanning incoming traffic, it installs sensors into the application or its runtime, often as an agent, a library linked into the app, or hooks placed in the runtime environment such as the JVM or the .NET CLR. Those sensors intercept the application's sensitive calls so RASP sees each operation as the code is about to perform it.

When a request flows through an instrumented application, RASP observes the whole path, not just the entry point:

1. Hook the sensitive operations. The sensors sit on the calls that matter for security: database queries, file system access, system command execution, deserialization, and outbound network calls. Every time the application reaches one of these, RASP gets control first.
2. Gather the runtime context. At the moment of the call, RASP has the data and the context around it: the input that produced the operation, the code path that led here, the configuration, the application logic, and the control flow. This is the information a perimeter device never sees.
3. Evaluate the operation. RASP analyzes the call against that context to decide whether it is legitimate or an attack. A string that pattern-matches as SQL injection but never alters the structure of a parameterized query is benign; one that does change the query structure is not. The decision is based on what the code is actually doing, which sharply reduces the false positives a signature-based control produces.
4. Act on the verdict. RASP takes one of three actions on the call: allow it, block it, or sanitize the input and let a safe version proceed. A blocked operation is terminated before it executes, so the injection never reaches the database and the malicious file is never opened.

The payoff of this design is that RASP makes its decision with ground truth. It is not inferring intent from the outside; it is watching the application execute and stopping the specific operation that would cause harm.

RASP modes: monitoring and blocking

RASP runs in one of two modes, and the choice is an operational decision, not a feature gap.

Monitoring (diagnostic) mode observes and alerts without interfering. RASP records the attacks it detects and the operations it would have blocked, but lets execution continue. This is how teams deploy RASP first: it surfaces real attack traffic and, just as important, exposes where blocking mode would break legitimate functionality, before any production request gets terminated.

Blocking (protection) mode actively stops attacks. When RASP identifies a malicious operation, it terminates that operation, ends the session, or returns an error to the caller, depending on configuration. This is the mode that delivers protection, and the standard path is to run in monitoring mode long enough to tune out the edge cases, then promote to blocking once the team trusts the verdicts.

The two-mode model is why RASP can be introduced into a production application without the disruption that an aggressive perimeter control causes when it false-positives on real users.

RASP vs WAF: inside the app vs the perimeter

The comparison defenders ask for most is RASP versus a web application firewall, because both protect applications from injection-class attacks and the two are routinely confused. They operate in completely different places, and that placement determines what each can and cannot do.

A web application firewall sits at the network perimeter and inspects HTTP and HTTPS traffic to and from the application. It filters requests against signatures and rules before they reach the app. It is effective and it scales across many applications from one chokepoint, but it has no visibility into what happens inside the application. It cannot see whether a request actually reaches a vulnerable code path, so it judges traffic on appearance, which produces both false positives on benign traffic and false negatives on obfuscated payloads it has no signature for.

RASP sits inside the application and judges behavior. It does not see traffic at the edge, so it cannot stop a volumetric flood or filter requests before they arrive, but it can confirm whether a request actually triggers a dangerous operation, and it keeps protecting the application even after an attacker is past the perimeter.

The two are not substitutes; they are complementary layers. A WAF thins out the volume and catches known patterns at the edge; RASP catches what gets through and confirms it against real execution. The reason to run RASP is exactly that perimeter defenses are porous, especially as applications move to the cloud and the network boundary blurs. RASP defends the application even after the perimeter is gone.

What RASP is good at, and where it falls short

RASP's strengths follow directly from running inside the application.

• Context-accurate detection. Because it sees the actual operation, RASP detects injection-class attacks, including SQL injection and cross-site scripting (XSS), with fewer false positives than a signature-based perimeter control, and it can catch obfuscated or novel payloads that no signature would match.
• Protection that survives a breached perimeter. When an attacker is already inside, RASP is still watching the dangerous operations and can stop them. Its protection is not tied to the network boundary.
• Deployment-environment independence. Because the protection travels with the application, it works the same whether the app runs on-premises, in a container, or in the cloud, which is the property that makes RASP relevant as the perimeter dissolves.
• Attack visibility for responders. RASP's code-level view of an attack, the input, the operation, the code path, is high-fidelity telemetry a SOC can use to understand exactly what was attempted and where.

The limits are just as real, and a defender should treat them as design constraints, not marketing caveats.

• Performance overhead. Instrumenting an application's sensitive calls adds work to each one. The overhead is usually modest but it is not zero, and it has to be measured against the application's latency budget.
• Per-application coverage. RASP protects the applications it is integrated into. It does nothing for an app that was never instrumented, and integration is per-app work, unlike a single WAF that fronts many.
• No perimeter or volumetric defense. RASP cannot stop a DDoS flood or filter traffic before it arrives. It is an internal control, not an edge control.
• It is not a substitute for fixing the code. RASP blocks exploitation of a flaw at runtime; the flaw is still in the code. It buys time and reduces risk, but it does not replace secure development, testing, or patching. Relying on RASP alone to cover unfixed vulnerabilities is the failure mode to avoid.

Where RASP fits in a DevSecOps program

RASP is the runtime layer of an application security program, and it earns its place by covering the stage the testing tools cannot: production, while the application runs. The other controls find flaws earlier. Static analysis and dynamic application security testing run before release to catch vulnerabilities in code and in the running build during testing. They reduce the number of flaws that ship. None of them are present when a real attacker hits the live application. RASP is.

In a DevSecOps model, security is wired through the lifecycle rather than bolted on at the end. The pre-deployment scanners, documented in resources like the OWASP DevSecOps Guideline, shrink the flaw count before release; RASP backstops the flaws that slip through, including ones no scanner flagged, by stopping their exploitation at runtime. The two halves are complementary: testing lowers the rate of vulnerabilities reaching production, and RASP contains the impact of the ones that do.

The practical sequence is to integrate RASP into the application, deploy it in monitoring mode to learn real traffic and surface false positives, tune, then promote to blocking. Run it alongside a WAF rather than instead of one, so the edge handles volume and known patterns while RASP handles context and post-perimeter defense. And keep feeding the fixes back: a flaw RASP blocks repeatedly is a flaw the development pipeline should be closing at the source.

How blue teams use RASP

RASP is built for the AppSec and DevSecOps side, but its output and its blind spots both matter to a defender.

Treat RASP alerts as high-confidence application telemetry. A RASP block is not a guess from the perimeter; it is a record that a specific dangerous operation was attempted against real code. That fidelity makes RASP events strong signal in a SIEM. A spike of blocked SQL injection attempts against one endpoint is a confirmed attack on a known-reachable code path, and it should rank above a WAF alert on the same traffic, which only saw the request shape.

Correlate the edge and the interior. A WAF alert says someone sent a suspicious request; a RASP block says the request actually reached a dangerous operation. Connecting the two tells a responder whether an attack got through the perimeter and hit live code, which is exactly the inside-versus-outside picture an intrusion investigation needs.

Watch the gaps RASP does not cover. RASP only protects instrumented applications and only sees application-level operations. It will not show a volumetric attack, will not cover an app no one integrated, and does not replace the patch. A blue team should know which applications carry RASP and which do not, and treat the uninstrumented ones as having no runtime safety net.

Frequently Asked Questions

What is runtime application self-protection (RASP)?

RASP is a security technology built into an application or its runtime environment that detects and blocks attacks in real time, using the application's own execution context. It instruments the running application, hooks sensitive operations such as database queries and file access, and evaluates each one against the data and code path that produced it. When an operation is malicious, RASP can allow, block, or sanitize it. Gartner coined the term in 2012.

How is RASP different from a WAF?

A web application firewall sits at the network perimeter and filters HTTP/HTTPS traffic against signatures before it reaches the app, with no visibility into what happens inside. RASP sits inside the application and judges actual behavior, so it knows whether a request reaches a dangerous operation and keeps protecting the app even after the perimeter is breached. A WAF scales across many apps from one chokepoint; RASP runs per application. They are complementary layers, not substitutes.

Does RASP replace secure coding and vulnerability scanning?

No. RASP blocks the exploitation of a flaw at runtime, but the flaw is still in the code. It backstops the vulnerabilities that slip past static and dynamic testing; it does not remove the need for them or for patching. Relying on RASP alone to cover unfixed vulnerabilities is the failure mode to avoid. Run it alongside pre-deployment testing, not instead of it.

What is the difference between RASP monitoring mode and blocking mode?

Monitoring (diagnostic) mode detects and alerts on attacks but lets execution continue, which is how teams deploy RASP first to learn real traffic and find false positives safely. Blocking (protection) mode actively terminates malicious operations, ends sessions, or returns errors. The standard path is to run in monitoring mode, tune out edge cases, then promote to blocking once the verdicts are trusted.

What attacks can RASP stop?

RASP is strongest against injection-class and application-layer attacks where execution context decides the verdict, including SQL injection and cross-site scripting (XSS). Because it sees the actual operation rather than just the request, it can catch obfuscated or novel payloads that a signature would miss. It cannot stop perimeter or volumetric attacks such as DDoS floods, because it runs inside the application rather than at the edge.

Who coined the term RASP and when?

Gartner analyst Joseph Feiman coined "runtime application self-protection" in 2012, in Gartner research naming it as an emerging application security technology. The category describes tools built into an application or its runtime that can control execution and detect and block attacks in real time, in contrast to perimeter controls that inspect traffic from outside.

Does RASP slow down an application?

It adds some overhead, because instrumenting an application's sensitive calls means RASP evaluates each one. The overhead is usually modest but it is not zero, so it has to be measured against the application's latency budget. This is one reason teams start in monitoring mode and test performance before promoting to blocking in production.

The bottom line

RASP protects an application from the inside. It instruments the running app, hooks the operations that matter, and decides whether each one is an attack based on what the code is actually doing, then allows, blocks, or sanitizes it. That execution context is what a perimeter device lacks, and it is why RASP produces fewer false positives and keeps working after an attacker is past the edge. Gartner named the category in 2012, and its relevance has grown as applications moved to the cloud and the network boundary stopped being a reliable line of defense.

The honest framing is that RASP is a layer, not a cure. It does not filter traffic at the perimeter, it only covers the apps it is integrated into, and it does not fix the flaw it blocks. Run it in monitoring mode first, promote to blocking once tuned, pair it with a WAF at the edge and with testing in the pipeline, and feed the blocks back to the developers closing the underlying bugs. For a defender, the value is the high-confidence runtime signal it produces. The way to make that instinctive is to work real application compromises. Start with CyberDefenders blue team labs and reconstruct how an application weakness became a breach.