Gartner estimates that 90% of web application attacks now target the application layer rather than the network perimeter, yet most organizations still lean on a single control — usually a WAF — to stop them. That gap matters because a Web Application Firewall and Runtime Application Self-Protection solve different problems: one filters traffic before it reaches your app, the other watches code execute inside it. Equifax's 2017 breach (CVE-2017-5638, an Apache Struts OGNL injection flaw) happened despite a WAF sitting in front of the affected system, because the payload didn't match any known signature. Log4Shell (CVE-2021-44228, disclosed December 9, 2021) exposed the same blind spot at massive scale: WAF vendors scrambled to ship regex patches for days while attackers rotated obfuscated JNDI strings faster than rules could keep up. This post breaks down how WAF and RASP actually work, where each fails, and when you need both.
What Is the Difference Between a WAF and RASP?
A WAF inspects HTTP/S traffic at the network edge before it reaches your application, while RASP instruments the application runtime itself to monitor and block malicious behavior as code executes. A WAF, like AWS WAF, Cloudflare, or F5 Advanced WAF, sits as a reverse proxy and matches requests against signatures, regex patterns, or ML-based anomaly scores defined in rulesets such as OWASP Core Rule Set (CRS) 4.x. RASP, by contrast, hooks into the application process — via a Java agent, .NET profiler API, or PHP extension — and inspects actual function calls, SQL queries, and file operations with full knowledge of the application's internal state. That's the core distinction: a WAF guesses intent from bytes on the wire; RASP observes ground truth inside the process.
How Does a WAF Actually Block Attacks?
A WAF blocks attacks by pattern-matching incoming requests against known-bad signatures and rate-limiting anomalous traffic before it reaches the origin server. For example, OWASP CRS 4.0 ships over 200 rule files covering SQL injection, XSS, and remote code execution patterns, scored cumulatively so a request exceeding a paranoia-level threshold (typically 5-20 points) gets blocked. This works well against commodity scanning — Akamai's 2023 State of the Internet report logged over 500 billion credential-stuffing attempts across monitored customers in a single year, most stopped at the edge. But WAFs are blind to encoding tricks, business-logic abuse, and zero-days with no published signature. Imperva's own 2022 research found that 90% of tested WAF configurations could be bypassed using basic payload obfuscation techniques like case randomization or Unicode normalization abuse, because the WAF never sees what the application actually does with the decoded input.
How Does RASP Detect and Stop Exploits at Runtime?
RASP detects exploits by monitoring the actual execution path — a SQL query builder, a deserialization call, a file-system write — and blocking it the instant it deviates from expected, safe behavior, regardless of how the malicious input was encoded. Because a RASP agent lives inside the JVM, CLR, or interpreter, it sees the same string a WAF would see after every layer of decoding, base64 unwrapping, and template evaluation has already happened. During Log4Shell, RASP tools from vendors like Contrast Security and Sqreen reported blocking exploitation attempts within hours of disclosure without a signature update, because the control fired on the actual JNDI lookup call (com.sun.jndi.ldap class loading), not on matching ${jndi:ldap:// in raw HTTP headers. The tradeoff is integration cost: RASP requires a language-specific agent deployed per service, and misconfigured agents can add 1-5ms of latency per request or, in rare cases, crash the process on an unhandled instrumentation error.
Which One Stops Log4Shell-Style Attacks Faster?
RASP stops novel injection-and-deserialization attacks like Log4Shell faster because it doesn't depend on a vendor publishing a new signature first. Cloudflare's own December 2021 incident writeup describes shipping four separate WAF rule updates within 72 hours of disclosure as attackers found new evasion strings — a reactive cycle that left windows of exposure measured in hours to days for anyone not on the very latest ruleset. RASP-protected applications, by contrast, were structurally immune the moment the agent was deployed, because the control logic ("don't let untrusted input reach a JNDI lookup or unsafe deserialization call") didn't need to know about log4j-core-2.14.1 specifically. The caveat: RASP only protects services where an agent is actually installed and healthy, so coverage gaps in a large microservices fleet — Safeguard customers commonly run 200+ services — translate directly into exposure gaps.
Do You Need Both WAF and RASP?
Yes — most mature application security programs run WAF and RASP together because they cover different attack stages and different asset types. A WAF is cheap to deploy fleet-wide (often a config change at the CDN or load balancer) and stops volumetric threats like credential stuffing, bot traffic, and known CVE scanning before they consume compute. RASP is more expensive to roll out per-service but catches the logic-layer and zero-day attacks that slip past signatures. Wiz's 2023 Cloud Security Threat Report noted that runtime detection caught active exploitation in cloud environments an average of several days before the corresponding CVE had a public patch available — a window where edge filtering alone provides no protection. Running both isn't redundant defense-in-depth theater; it's matching each control to the failure mode it's actually good at catching.
What Are the Cost and Performance Tradeoffs?
WAFs are cheaper and faster to deploy but carry ongoing tuning overhead, while RASP costs more per service to instrument but requires far less rule maintenance once deployed. A managed WAF typically runs $200-$5,000+/month depending on request volume and vendor, with a security engineer spending recurring hours tuning false positives — Salt Security's 2023 API survey found 61% of respondents citing false-positive rate as their top complaint with signature-based tooling. RASP agents are usually licensed per-application-instance, which gets expensive fast across a large service fleet, and each new language runtime (Java, Node, Python, Go) needs its own agent with its own performance characteristics. The realistic calculus: WAF for broad, cheap edge coverage against commodity attacks; RASP for your highest-value, highest-risk services where a few milliseconds of latency and a per-instance license are worth it to catch what signatures miss.
How Safeguard Helps
WAF and RASP both operate downstream of the real question: is the vulnerable code path actually reachable and exploitable in your specific application? Safeguard's reachability analysis traces whether a flagged dependency's vulnerable function is ever called from your application's live code paths, cutting through the alert noise that makes teams under-invest in runtime controls in the first place. Griffin, Safeguard's AI analysis engine, correlates SBOM data — whether generated directly from your build or ingested from existing CycloneDX/SPDX files — against active exploit intelligence to prioritize which services most need a RASP agent versus which are fully mitigated by network-layer filtering. When a fix is available, Safeguard opens an auto-fix pull request with the patched dependency version rather than just another dashboard alert, closing the gap between detection and remediation before either your WAF or RASP ever needs to fire.