Runtime application security protection (RASP) is a class of security control that instruments an application's own runtime — the JVM, the .NET CLR, the Node process — so it can detect and block attacks as they execute, using the application's actual context rather than pattern-matching on network traffic. Instead of inspecting HTTP requests from outside like a web application firewall does, a RASP agent sits inside the process and watches what the code itself is about to do: which SQL string is about to run, which file path is about to open, which shell command is about to spawn. That inside view is both RASP's biggest advantage and the reason it's misunderstood as a replacement for testing earlier in the pipeline. It isn't. It's a last line of defense for the vulnerabilities that made it to production anyway.
How does runtime application security protection actually work?
A RASP agent gets loaded into the application process at startup, usually through the same instrumentation mechanism as an APM tool — a Java agent flag, a native Node module, a .NET profiler. Once loaded, it hooks the sensitive sinks a security team cares about: database drivers, file I/O, process execution, deserialization calls, outbound HTTP. When a request flows through the app, the RASP agent watches the actual function calls that request triggers, and if a database call is about to execute with a query string that looks like it was built from unsanitized user input concatenated with SQL keywords, the agent can block that specific call before it reaches the driver. This is fundamentally different from a signature-based tool inspecting the request body for suspicious strings — RASP sees the tainted data and the vulnerable sink in the same execution context, which is why it produces far fewer false positives than perimeter tools tuned only on request shape.
How is RASP different from a WAF?
A web application firewall inspects traffic at the network edge without any knowledge of what the application code does with that traffic; RASP inspects the application's internal execution and has full knowledge of both the incoming data and the sink it's headed toward. A WAF has to guess, from the shape of a request, whether ' OR '1'='1 is an attack — and it guesses wrong often enough that most WAF deployments run in "detect and log" mode for months before anyone trusts blocking mode. RASP doesn't need to guess: it watches the actual query get assembled and can tell, deterministically, whether user-controlled data ended up somewhere it shouldn't. That precision comes at a cost — RASP requires language-specific agents (a Java RASP module says nothing about your Python service), while a WAF sits in front of everything regardless of what's behind it. Most mature programs run both: a WAF for volumetric abuse, bot traffic, and known bad IPs at the edge, and RASP for the application-logic attacks that only make sense once you know what the code is doing.
Where does RASP fit next to SAST and DAST?
RASP is a production safety net, not a replacement for testing the code before it ships — SAST and DAST still do the job of finding vulnerabilities before release, and RASP catches the ones that got through anyway or that only manifest under real production traffic patterns. Static analysis reads source code and flags a SQL injection risk at the line where a query is built from a request parameter; dynamic testing throws real attack payloads at a running app in staging and confirms the flaw is actually exploitable. RASP does neither of those things — it doesn't scan code and it doesn't run test payloads, it just watches live traffic and blocks the sinks it's configured to protect. Teams that skip SAST/DAST and rely on RASP alone end up patching in production what should have been caught in a pull request, and they lose the ability to fix the root cause because RASP suppresses the symptom without ever touching the source.
What kinds of attacks does RASP actually catch?
RASP is strongest against injection-class attacks where the vulnerable sink is deterministic and observable at runtime: SQL injection, command injection, unsafe deserialization, path traversal, and server-side request forgery. Because the agent instruments the actual sink — the exec() call, the file open, the deserializer — it can block the exact operation regardless of how the malicious input was encoded or obfuscated on the way in, which is where signature-based tools at the edge routinely get bypassed. It's weaker against business-logic abuse, broken access control, and anything that looks like a perfectly legitimate request executing perfectly legitimate code (an authenticated user hitting an endpoint they shouldn't have access to looks the same to a RASP agent as one who should). That gap is exactly why access control testing belongs in DAST and manual review, not in a runtime agent's job description.
What does RASP cost in performance and operational overhead?
Every RASP agent adds latency and CPU overhead because it's intercepting function calls on the hot path of every request, typically in the range of 1-5% overhead for a well-tuned agent and noticeably more for a poorly configured one hooking too many sinks. That overhead is the tax for the precision RASP offers, and it's usually worth paying only for internet-facing services handling untrusted input directly — an internal batch job with no external attack surface gets little from RASP and pays the tax anyway. Operationally, RASP agents need the same lifecycle discipline as any other production dependency: they need updating when the language runtime updates, they can introduce their own bugs (an agent hook is still code, and it can crash a request path it was supposed to protect), and they need their own on-call ownership. Teams that bolt on RASP without a plan for who monitors and updates the agent end up with a security control that quietly stops working after the next framework upgrade.
FAQ
Is RASP the same as an EDR agent?
No. Endpoint detection and response protects the host operating system and its processes generally; RASP protects one specific application's internal logic. They can coexist on the same server without overlapping.
Does RASP replace a WAF?
No. RASP and a WAF cover different layers — the WAF handles network-level and volumetric threats before requests reach the app, RASP handles application-logic attacks once the app is processing them. Most production stacks that use RASP keep the WAF too.
Which languages support RASP well?
Java and .NET have the most mature RASP tooling because their runtimes expose rich instrumentation hooks (Java agents, CLR profilers). Node.js and Python support is improving but historically had fewer mature commercial options.
Can RASP replace SAST/DAST in a compliance program?
Rarely. Most compliance frameworks and secure-SDLC requirements expect pre-release testing like SAST and DAST; RASP is typically documented as a compensating runtime control, not a substitute for testing before deployment.