RASP — Runtime Application Self-Protection — is a security technology that runs inside an application and protects it from within. By instrumenting the application's runtime, RASP observes how input is actually used and can detect and block attacks at the moment of exploitation, with context a perimeter defense never sees.
How does RASP work?
RASP attaches to the application's runtime — a JVM agent, a .NET profiler, a Node instrumentation hook — and intercepts security-relevant operations: database queries, file access, command execution, deserialization. When a request's data reaches one of those operations in a way that matches exploitation (a parameter that rewrites the SQL structure, a path that escapes its directory), RASP can log it, alert, or block the operation in-process.
The defining property is context. A perimeter filter guesses maliciousness from the request's shape; RASP watches what the code actually does with it, which collapses most of the false-positive/false-negative trade-off.
RASP vs WAF vs client-side monitoring
| WAF | RASP | Browser-layer monitoring | |
|---|---|---|---|
| Where it runs | In front of the app | Inside the server runtime | In the visitor's browser session |
| Sees | Requests and responses | Actual code execution | Scripts executing on the page |
| Blind spot | How input is used | Everything client-side | Server internals |
| Stops | Known attack patterns | Exploits reaching the runtime | Skimming, injected scripts, data exfiltration |
| Deployment | Network-level | Per language/runtime agent | Script tag |
Where RASP stops
RASP's boundary is the server process. Everything that happens after the response leaves — the JavaScript your page and its dozens of third-party vendors execute in the visitor's browser — is invisible to it. A compromised analytics tag skimming a checkout form never touches the instrumented runtime; from the server's perspective, nothing abnormal occurred.
That client-side gap has its own attack classes — JavaScript injection, DOM-based XSS, Magecart — and, for payment pages, its own regulatory response in PCI DSS 4.0.1's script-inventory and tamper-detection requirements (6.4.3 and 11.6.1).
The browser-layer equivalent
The idea behind RASP — watch the runtime, not the perimeter — applies equally to the browser, where the "runtime" is every script executing in a real session. That is what cside's client-side monitoring does: it observes what each script actually does as it runs — DOM access, form reads, outbound requests — and flags behavior that shouldn't be there. cside is not a RASP; it is the same protection philosophy applied to the half of the application RASP cannot see. Most mature stacks end up with a WAF at the perimeter, RASP or equivalent controls in the server runtime, and runtime monitoring in the browser — layered client side security rather than any single box.
