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 |
Web Application Firewalls sit between users and your application. They inspect HTTP traffic against rules and signatures — blocking known attack patterns like SQLi payloads and XSS vectors. They're easy to deploy (often just a DNS change for cloud WAFs) and protect without code changes. The limitation is they only see HTTP and lack application context, leading to bypasses and false positives.
Runtime Application Self-Protection instruments the application from inside. It sees the full data flow — from HTTP input through code execution to database queries. If a SQL string built from user input reaches a query, RASP catches it regardless of encoding or obfuscation tricks that bypass WAFs. The cost is language-specific agents and production runtime overhead.
WAFs are your first line — they block the obvious attacks and reduce noise. RASP catches what gets through, especially encoded payloads and business logic attacks the WAF can't understand. Defense in depth means running both rather than choosing one.