One guards the perimeter. The other guards the runtime. Both have blind spots.
| WAF | RASP | |
|---|---|---|
| Position | Network edge, in front of the app | Inside the application runtime |
| Visibility | HTTP requests and responses only | Full application context + data flow |
| Protection model | Pattern matching, signatures, rules | Code-level analysis of data flow |
| DOM XSS detection | Cannot see it (client-side only) | Can detect if JS engine is instrumented |
| False positives | Higher — no application context | Lower — sees actual code behavior |
| Deployment | Reverse proxy or CDN integration | Language-specific agent in the app |
| Performance impact | Minimal — separate from app | Some overhead — runs in-process |
A WAF inspects traffic before it reaches your application and decides whether to pass it on. RASP runs inside the application and decides, at the moment a dangerous operation is about to happen, whether to allow it. The WAF has to guess what a request will do; RASP can see what it did.
Can you deploy code into the runtime? This is the first gate and it eliminates most of the debate. RASP requires an agent inside the application process, which means a supported language, a deployment you control, and a team willing to accept an in-process dependency. A WAF needs none of that — it sits in front of anything that speaks HTTP, including the vendor appliance nobody can patch.
What are you actually buying it for? If the honest answer is "a compliance requirement says we need one", that's a WAF, and there's no point pretending otherwise. If it's "we have a known-vulnerable application we can't fix this quarter", a WAF buys a virtual patch quickly. If it's "we want fewer false positives and real attack telemetry from production", that's the RASP argument.
What's your tolerance for blocking legitimate traffic? Both can, and the failure modes differ. A WAF tuned aggressively blocks users whose input merely resembles an attack — the classic case being anyone whose surname or password contains a quote, or a developer pasting SQL into a support ticket. RASP blocks based on what the application is about to do, so its false positives are rarer but occur deeper in the request, sometimes after a partial state change.
The honest framing is that neither is a substitute for fixing the bug. Both are compensating controls, and the most common way organizations get hurt is by treating a WAF rule as remediation and closing the ticket.
The application concatenates a sort parameter into a query. An attacker sends sort=name');DROP TABLE--.
The WAF sees a string containing SQL keywords and quote characters in a query parameter, matches a signature, and blocks with a 403. It never learns whether that parameter reaches a database at all. Now the attacker starts encoding: comment injection between keywords, alternate whitespace, case variation, chunked transfer encoding, HTTP parameter pollution. Each bypass is a fight between the WAF's parser and the application's, and the attacker gets unlimited attempts. Meanwhile a legitimate user searching for a product named "Bob's Tools" is also getting a 403.
RASP ignores the request shape entirely. It has instrumented the database driver, so at the moment execute() is called it compares the query's parse tree against the parameters that came from the request. It sees that user input has introduced new SQL syntax — a statement terminator and a new command — rather than filling a value slot. That's a structural fact about what the query became, not a guess about what the string looked like, so encoding tricks don't help and "Bob's Tools" doesn't trigger anything because it never changed the query's structure.
WAF. ModSecurity with the OWASP Core Rule Set is the open-source baseline and still the best way to understand what rule-based filtering actually does. Cloudflare, AWS WAF and Azure Front Door bundle it with a CDN, which is how most teams acquire one. The managed services matter less for their rules than for the surrounding capabilities: rate limiting, bot management and DDoS absorption, which are genuinely things an application cannot do for itself.
RASP. A smaller commercial market — Contrast, Imperva and Datadog's application security product are the names you'll encounter, usually bundled with IAST or APM since the instrumentation is the same investment. Language support is the practical constraint: Java and .NET are well covered, Node and Python less consistently, Go and Rust barely at all because there's no runtime to hook the way there is on a JVM.
Many teams end up with both, and that's a reasonable outcome: the WAF at the edge handles volumetric attacks, bots and broad scanning noise, while RASP handles the precise application-layer decisions. See SAST vs DAST vs IAST vs RASP for how RASP relates to the testing tools that share its instrumentation.
Authorization. Neither a WAF nor RASP knows that this authenticated user should not be permitted to read invoice 1041, because nothing about that request is malformed — it's a perfectly ordinary request for a record that happens to belong to somebody else. Broken access control is the most common serious finding in real applications and sits entirely outside what either control can reason about. The same goes for business logic: applying a coupon twice, refunding a negative amount, racing a checkout. Every request involved is valid.
It stops unsophisticated attempts and scanner noise, which is genuinely useful. It does not reliably stop a determined attacker, because signature matching is a parsing contest the attacker can retry indefinitely. Treat it as a speed bump and a telemetry source, not as remediation.
It's a different control with a different trade. RASP has far better context, so it has fewer false positives and is much harder to bypass by encoding. It also requires an agent in your runtime, supports fewer languages, and cannot protect anything you can't instrument — which includes most third-party software.
Yes, and many organizations do. The WAF handles edge concerns — rate limiting, bots, volumetric attacks, scanning noise — while RASP makes the precise in-application decisions. They're complementary rather than redundant.
There is real overhead, typically in the low single-digit percentages for mature agents, concentrated at the instrumented call sites. Whether that matters depends entirely on your latency budget; it is worth measuring under load rather than trusting a datasheet.
Often yes on paper — PCI DSS has historically accepted a WAF as an alternative to code review for public-facing applications. That's a statement about the auditor's checklist, not about your risk, and it's the single most common reason WAFs get deployed and then never tuned.