RASP vs WAF: Where to Place Edge and In-App Protection

Teams usually start asking about runtime application self-protection (RASP) when their web application firewall (WAF) has been stuck in detection mode for months because blocking breaks real traffic. A WAF judges a request at the edge from what the request looks like; RASP judges it inside the running application from what the request actually does when it reaches a database call, a file operation or a command. That difference drives everything else: false positive rates, bypass resistance, performance cost, language coverage and how each one fails. This guide compares the two as placement decisions, with threat models, failure modes and deployment choices by application type, for AppSec engineers, platform teams and security architects. Product selection is covered in the Runtime Application Self-Protection (RASP) buyer's guide and agent internals in the Interactive Application Security Testing (IAST) and RASP Guide.

Key takeaways

• Context is the core difference. NIST SP 800-53 SI-7(17) describes RASP as using information from the software in execution, and contrasts it with perimeter protections that see only network information without contextual awareness.
• The WAF still owns the edge. Volumetric traffic, bots, rate limits, geo and IP reputation, and protection for applications you cannot instrument all stay at the edge.
• RASP pays off where WAF tuning hurts most. Injection and deserialisation classes that generate WAF false positives are judged at the sink, where an input either changed the query or command or it did not.
• Each fails differently. A WAF fails open on oversize bodies, unparsed content types and over-broad exclusions; RASP fails on runtimes it does not support and on agent faults inside the application process.
• Neither stops logic flaws. Broken object level authorisation and abuse of business flows look like valid requests to both, so authorisation in code and API controls remain necessary.

The short answer

Keep the WAF, and add RASP to the applications where the WAF cannot block confidently: high-value applications on runtimes the RASP agent supports, applications with rich input that defeats signature tuning, and applications carrying known vulnerable components you cannot patch quickly. Use the WAF alone for applications you cannot instrument (commercial packages, appliances, unsupported languages) and as the first layer for everything internet-facing. Do not buy RASP to fix a WAF that was never tuned; first check whether the WAF is in the right paranoia level with narrow exclusions, as covered in the Web application firewall (WAF) health check.

The WAF as an architecture

Threat model: internet-scale opportunistic attacks against public-facing applications (MITRE ATT&CK T1190 Exploit Public-Facing Application), bots, scanners and floods. The WAF assumes it can recognise a malicious request by its content or its behaviour before the application sees it.

Architecture in words: traffic terminates TLS at the WAF or the edge in front of it, the request is parsed, normalised and scored, and it is either forwarded or blocked. In the OWASP Core Rule Set (CRS), used in ModSecurity and in managed rule sets such as the Azure Application Gateway CRS policies, each matching rule adds to an anomaly score (5 for critical, 4 for error, 3 for warning, 2 for notice) and the request is denied when the inbound score reaches the threshold, which the CRS project recommends keeping at 5. Paranoia levels 1 to 4 add progressively stricter rules: level 1 rarely raises false alarms, level 2 suits sites handling personal data, and levels 3 and 4 bring many false positives that need rule exclusions.

Failure modes:

• Inspection limits: managed WAFs inspect a bounded portion of the body. Platforms are listed alphabetically here and the limits are each provider's documented settings. AWS WAF inspects the first 8 KB of the body for Application Load Balancer and AppSync, and 16 KB by default (configurable up to 64 KB) for CloudFront, API Gateway and several other resource types; oversize handling is set per rule as Continue, Match or No match, with Continue the default outside the console. Microsoft Azure Application Gateway WAF on CRS 3.2 or later exposes separate settings for request body inspection, the maximum inspection depth, body size enforcement and file upload enforcement; in detection mode it inspects up to the limit and ignores the rest. Choose the oversize behaviour deliberately for every application.
• Unparsed content: the CRS documentation warns that allowing extra content types without the right body parser may result in a complete WAF bypass. GraphQL, gRPC, custom JSON nesting and multipart edge cases all need checking.
• Exclusion creep: every false positive is fixed by an exclusion. Whole-rule removals instead of narrow, location-scoped exclusions erode protection silently.
• Threshold drift: the CRS documentation says thresholds should only be raised temporarily during false positive tuning, and notes that some vendors ship higher defaults than CRS.

Controls that make it work: start blocking at a high threshold and lower it as false positives are resolved, raise paranoia levels using the executing paranoia level (rules log without blocking), keep exclusions narrow and in version control, and review them quarterly. Rollout detail is in the Web application firewall (WAF) rollout playbook.

RASP as an architecture

Threat model: exploitation of vulnerabilities in the application and its libraries, including attacks crafted to look harmless at the HTTP layer. RASP assumes the clearest evidence of an attack is the moment untrusted input changes what the code does.

Architecture in words: NIST SP 800-53 Rev. 5 SI-7(17) describes RASP as runtime instrumentation that detects and blocks exploitation by using information from the software in execution, monitoring inputs and blocking those that could allow attacks, and protecting the runtime from unwanted changes and tampering. On detection it can warn the user, terminate the session, terminate the application or alert personnel, and it can run in monitor or protection mode. The agent hooks sinks such as database drivers, file APIs, process execution, deserialisers and HTTP clients, tracks which values came from the request, and checks at the sink whether that data altered the operation (an extra SQL clause, a path outside the allowed directory, a forbidden class, an outbound call to an internal metadata address).

Failure modes:

• Uncovered runtimes: RASP protects only what it instruments. A Go service, a legacy language, an unsupported framework version or a serverless runtime outside the agent's support matrix gets nothing, often without anyone noticing.
• Agent faults in production: the agent runs in the application process. A bad agent update, a compatibility issue after a framework upgrade or a blocking rule that terminates the application rather than the request can cause an outage that the WAF team would never have caused.
• Overhead on hot paths: instrumented calls add work inside the request. Measure it on your own workload during the pilot; do not rely on vendor benchmarks.
• Agent as an attack surface: agents carry keys to a management console and send data (stack traces, payloads) out of the application. See Securing the IAST and RASP agent itself.

Controls that make it work: start every application in monitor mode, choose the session or request as the default response rather than terminating the application, pin and stage agent versions through the same pipeline as application releases, and keep a documented switch to monitor mode for rollback.

Detection context and bypass resistance

The table shows where each layer has the information to decide. "Strong" means the layer can usually block confidently; "weak" means it can only guess or cannot see the attack.

Bypass resistance follows from this. A WAF has to predict every way the application will decode input, and the OWASP Virtual Patching Cheat Sheet notes that deny-list rules are more prone to evasion than positive security rules. RASP does not need to predict the decoding, because it checks the value after the application has processed it. RASP is not bypass-proof: an operation that is not instrumented, or an attack that abuses intended functionality, passes it just as it passes the WAF.

Performance and language coverage

• Where latency lands: WAF processing adds latency at the proxy and scales by adding proxy capacity; runtime exclusions add a small per-transaction cost according to the CRS documentation. RASP adds work on each instrumented call inside the application, so the cost scales with the application and is paid on its CPU budget.
• How to measure: run the same load test with the agent off, in monitor mode and in protection mode, and compare p95 and p99 latency, CPU and memory per pod or instance. Hold the release if the difference breaks the service level objective.
• Language and framework coverage: build a runtime inventory (language, version, framework, hosting model) for every application in scope and compare it with the agent's published support matrix before committing. Mixed estates usually end with RASP on a subset and WAF everywhere.
• Serverless and managed runtimes: check whether the agent supports the function runtime and the cold start cost; where it does not, the WAF or API gateway in front of the function is the only inline control.
• Commercial and third-party applications: you usually cannot add an agent to a vendor-supported package without affecting support terms, so these stay WAF-only.

Deployment by application type

When WAF tuning pain is the trigger

Use this checklist before deciding that RASP is the answer to a noisy WAF.

1. Confirm the WAF is tuned, not just noisy. Check the paranoia level against the data the application handles, the anomaly threshold, and whether exclusions are narrow and scoped to locations.
2. Classify the false positives. If most come from injection rules on rich text, JSON or code-like input, RASP addresses the cause. If they come from protocol, bot or rate rules, RASP will not help.
3. Check runtime coverage. If the noisy applications run on runtimes the agent does not support, RASP is not an option for them.
4. Pilot RASP in monitor mode alongside the WAF. Compare which attacks each flagged over several weeks of real traffic and controlled tests by your assessment team.
5. Move blocking to RASP for the covered attack classes. Keep the WAF rules for those classes at a lower paranoia level, rather than removing them, so the edge still blocks the obvious traffic.
6. Keep rollback simple. One switch to return RASP to monitor mode and one to restore the previous WAF configuration, both tested before go-live.

A worked example: a payments portal on a supported Java framework has its WAF in detection mode because a rich-text support form triggers SQL injection rules daily. The team keeps the WAF in blocking mode at paranoia level 1 with bot and rate rules, adds a narrow exclusion for the form field at the WAF, and relies on RASP in protection mode to block any input that changes a query at the database driver. The form works, injection is still blocked, and the remaining WAF exclusions are fewer and documented.

Where identity fits

Both layers run with credentials. RASP agents authenticate to a management console with keys that can change blocking policy, and cloud WAFs or WAF appliances run under workload roles. In the Capital One breach (2019), an attacker abused a misconfigured web application firewall to obtain temporary credentials for its cloud role, and that role could read far more storage than a firewall needed. Scope the WAF's role to what it needs, require session-token metadata access, rotate RASP agent keys, and alert when either identity does something outside its job. The Securing the web application firewall (WAF) itself page covers the WAF side.

Common failure patterns

• Blocking mode switched on without a baseline: a WAF paranoia level raised, or RASP moved to protection mode, without a monitor period, followed by an outage and a rollback to detection mode that never ends.
• RASP terminating the application: the application-level response used as the default, so one malicious request takes the service down for every user.
• Assumed coverage: RASP reported as deployed across the estate when half the services run on unsupported runtimes, so dashboards show protection that does not exist.
• Oversize and content type gaps: WAF rules that never see the part of the body or the content type that carries the attack.
• Virtual patches that become permanent: WAF or RASP rules shielding a known vulnerable component with no remediation ticket or end date, which the OWASP virtual patching guidance warns against.
• WAF removed after RASP arrives: edge controls for bots, floods and unsupported applications lost because the in-app layer was assumed to cover everything.

Detection and measurement

Send WAF decisions and RASP events to the same SIEM with a shared request identifier, so one attack can be followed through both layers. Alert on RASP blocks for attack classes the WAF allowed (a tuning signal for the edge), agent disconnections, mode changes and new exclusions.

Framework mapping

Practitioner checklist

• Inventory internet-facing applications with runtime, framework, hosting model and current WAF mode.
• Review WAF paranoia level, anomaly threshold, oversize handling and content type parsing per application.
• Replace whole-rule WAF exclusions with narrow, location-scoped exclusions held in version control.
• Pilot RASP in monitor mode on high-value applications with supported runtimes and measure latency.
• Set RASP responses to block the request or session, never terminate the application by default.
• Keep WAF bot, rate and baseline rules in place after RASP goes live.
• Link every virtual patch to a remediation ticket with a due date.
• Scope WAF workload roles and rotate RASP agent keys; alert on unusual activity by either.
• Correlate WAF and RASP events by request identifier in the SIEM.

Standards and references

• NIST: SP 800-53 Rev. 5 (SI-7(17) Runtime Application Self-protection)
• OWASP Core Rule Set: Anomaly Scoring
• OWASP Core Rule Set: Paranoia Levels
• OWASP Core Rule Set: False Positives and Tuning
• OWASP: Virtual Patching Cheat Sheet
• OWASP: API Security Top 10 2023
• AWS: AWS WAF body inspection size limits
• Microsoft Learn: Application Gateway WAF request and file upload size limits

Related NHI Mgmt Group resources: Web Application Firewall Guide · Interactive Application Security Testing (IAST) and RASP Guide · Runtime Application Self-Protection (RASP) · WAF vs API Gateway · DAST vs IAST