WAF performance depends more on rules than engine choice

At a glance

What this is: This benchmark compares three Envoy WAF flavors and shows that rule-set scope, not the WAF engine itself, is the main driver of performance cost.

Why it matters: IAM and security teams should treat WAF policy design as a governance decision, because inspection depth and body parsing affect whether protection can be sustained in production.

By the numbers:

• Full OWASP CRS on 1 KB bodies sustained about 1,000 RPS per 6-core instance with a 4.86 ms p99 on TEG WAF.
• Full CRS on larger bodies drove CPU cost to about 18.15 cores per 1,000 RPS at 50 KB.
• Peak memory stayed under 80 MB with targeted rules but rose to 100-205 MB under full CRS.

Context

Web application firewalls are only useful when they can be sized and tuned for the traffic they actually see. In practice, teams often argue about proxy choice or engine implementation before they understand how much of the cost comes from the ruleset, request-body inspection, and logging path.

This benchmark is therefore best read as a governance and capacity-planning exercise, not a product comparison. The article shows that protection depth changes the operating envelope far more than the WAF engine itself, which matters for any team using WAFs to protect web applications, APIs, and adjacent identity-sensitive flows.

Key questions

Q: How should teams size a WAF when rule sets vary by route?

A: Size it by the heaviest policy that a route will actually carry, then validate the p99 latency and CPU headroom at that depth. A small header-only policy and a full body-inspecting CRS can differ by orders of magnitude, so blanket capacity assumptions usually understate the real cost.

Q: Why does full OWASP CRS cost so much more than targeted WAF rules?

A: Full CRS evaluates hundreds of checks against every request, including body parsing and rule-phase execution. Targeted rules inspect far fewer conditions, so the runtime cost stays close to the proxy baseline. The difference is not the WAF concept itself, but how much security logic the request has to traverse.

Q: What are the signs that a WAF policy is too broad for production?

A: Watch for rising p99 latency, CPU saturation, and memory growth when request bodies are enabled or when broad rule groups are added. If those signals appear only after deep inspection is switched on, the policy is probably broader than the route set can sustain without service impact.

Q: Should security teams prioritise selective inspection over blanket CRS coverage?

A: Yes, unless every protected route has the same exposure and latency tolerance. Most environments do not. Selective inspection lets teams reserve heavy-body parsing and high-paranoia rules for the few paths that need them, while keeping the rest of the traffic on a lighter policy.

Technical breakdown

Why the WAF engine cost stays low in targeted policies

A WAF only pays its full cost when it has to parse bodies, evaluate rules, and inspect every request path in the filter chain. In the benchmark, the minimal policy used only a handful of header and injection-detection rules, so the fixed cost was mostly body buffering and phase execution rather than complex matching. That is why every flavor sustained the load ceiling and why latency stayed low. The key point is that a WAF engine is not the same thing as a WAF posture: narrow rules keep the runtime cheap, but they also limit the threat surface being inspected. See the Web Application Firewall Guide. See the Web Application Firewall Guide.

Practical implication: Treat rule scope as the first capacity variable when you size a WAF, not the proxy engine alone.

How full OWASP CRS changes the performance profile

The full Core Rule Set is a different workload because hundreds of rules run against each request, and request-body parsing magnifies the cost. That moves the dominant variables to regex evaluation, body buffering, and per-request rule-phase overhead. The benchmark shows the C-accelerated build outlasting the others as payload size grows, but the broader lesson is architectural: broad inspection depth consumes capacity quickly, especially on body-bearing traffic. When teams assume a firewall policy can be turned up globally without consequence, they usually underestimate the cost of evaluating broad security logic at line rate. See the Web Application Attacks Guide. See the Web Application Attacks Guide.

Practical implication: Scope full-body inspection only to routes and request types that genuinely need it.

Why capacity planning for WAFs is really policy planning

Capacity planning for a WAF is often described as a hardware problem, but the benchmark shows it is a policy problem first. The same Envoy data plane behaves very differently depending on whether you load a few custom rules or the full CRS, and the cost rises sharply as payload size increases. That means protection teams need to map inspection depth to business-critical routes, acceptable latency, and backend sensitivity before they size replicas. For identity-adjacent applications such as login, token exchange, or session endpoints, the wrong rule scope can either leave blind spots or create latency that teams will be tempted to disable. See the Firewall Management Guide. See the Firewall Management Guide.

Practical implication: Align WAF policy tiers to application criticality and latency tolerance before you scale infrastructure.

NHI Mgmt Group analysis

Rule-set scope is the real control boundary: the benchmark shows that WAF performance is governed far more by policy breadth than by the engine itself. That means the operational question is not which proxy is faster, but which routes deserve body inspection, injection detection, and full CRS coverage. For security programmes, this is a control-design issue, not a vendor choice issue.

Capacity planning and policy design have merged: once broad rule sets are enabled, tail latency, CPU consumption, and memory footprint become part of the control decision. Teams that treat WAF tuning as a post-deployment task will either over-provision unnecessarily or quietly narrow inspection to preserve service performance. The governing principle is route-specific inspection, not blanket enforcement.

WAFs are now part of application governance, not just perimeter defence: the benchmark is especially relevant for identity-sensitive web paths where authentication, sessions, and API calls share the same front door. If login or token endpoints inherit a full-body inspection policy intended for every route, the result can be avoidable friction or unsafe exceptions. That makes web application security testing and route-level policy review part of the same governance conversation.

Full CRS only works when organisations accept the cost of depth: the article shows that broad request-body inspection is operationally feasible, but only when teams budget for the CPU and memory it consumes. That shifts the question from whether CRS can run to where it should run. Practitioners should treat broad WAF coverage as a selectively deployed control, not a universal default.

Named concept: policy-weighted inspection cost: the benchmark defines the difference between a cheap engine and an expensive rule set. The cost of a WAF comes from how much policy you ask it to execute, not simply from attaching a filter to the request path. Practitioners should measure WAF depth by route and payload size before they standardise a deployment model.

What this signals

Policy-weighted inspection cost: the benchmark makes a simple point that many WAF programmes miss. The expensive part is not adding a WAF layer, but asking it to evaluate broad rule sets across body-bearing traffic. That means route classification, payload size, and rule depth should sit in the same design review as capacity targets.

Teams that treat WAF tuning as a one-time deployment step will struggle to keep inspection aligned with application change. As APIs, upload flows, and authentication endpoints evolve, the inspection policy has to be re-evaluated or the organisation will either lose coverage or pay for unnecessary depth.

For identity-heavy web applications, the practical implication is straightforward: the WAF policy must be mapped to the security value of each route. Login, session, and token-handling paths often justify stricter inspection than static or low-risk traffic, but not every endpoint needs the same rule burden.

For practitioners

• Measure WAF cost by rule tier, not by brand Benchmark header-only, targeted, and full-CRS policies separately so capacity planning reflects the actual inspection depth you intend to run.
• Scope body inspection to the routes that need it Apply request-body parsing and deep inspection only to endpoints that carry meaningful attack exposure, such as login, upload, and API submission paths.
• Set latency budgets before enabling broad CRS coverage Define acceptable p99 latency and CPU ceilings for each application class before enabling full OWASP CRS across production traffic.
• Review WAF policy as part of change control Treat rule additions, exclusions, and paranoia-level changes as controlled security changes with owners, justification, and rollback criteria.

Key takeaways

• The article shows that WAF performance is constrained more by rule-set scope than by the underlying engine choice.
• Full OWASP CRS on body-bearing traffic materially increases CPU, memory, and tail-latency cost, which changes how teams size deployments.
• The practical answer is route-specific inspection and policy review, not blanket enforcement everywhere.

Related NHI Mgmt Group resources: Web Application Firewall Guide · Web Application Attacks Guide · Firewall Management Guide · Web Application Security Testing Guide

Key terms

• Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.
• Request-Body Inspection: Request-body inspection is the process of parsing and evaluating the payload of an HTTP request for malicious content or policy violations. It increases detection depth, but it also adds processing cost, so teams must balance coverage against latency and throughput requirements.
• OWASP Core Rule Set: The OWASP Core Rule Set is a widely used set of ModSecurity-compatible rules that detects common web attack patterns such as injection and malicious request behaviour. In practice, its performance footprint depends heavily on how many rule groups are enabled and whether body inspection is turned on.
• Tail Latency: Tail latency is the slow end of a system's performance distribution, usually measured with metrics such as P95 or P99. Security teams care about it because the outliers are often the scans, checks, or reviews that block production workflows and erode trust in the control.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suitable for practitioners who need to connect identity governance to the wider security controls their programmes depend on.