DEV Community

Cover image for Measuring web application firewall performance: real numbers from private cloud deployments
binadit
binadit

Posted on • Originally published at binadit.com

Measuring web application firewall performance: real numbers from private cloud deployments

#webapplicationfirewall #waftuning #privatecloud #performanceoptimization

WAF performance benchmarks: what 2000 concurrent users taught us about private cloud security

Your web application firewall is slowing down your app. The question is: by how much, and is it worth it?

We ran comprehensive performance tests on five different WAF configurations to find out exactly what you're trading when you add security layers to high-traffic applications. The results might change how you think about WAF deployment.

The performance cost nobody talks about

Every security rule adds latency. Every pattern match consumes CPU cycles. For applications handling thousands of requests per hour, a poorly configured WAF can kill performance faster than any DDoS attack.

Our testing revealed that default WAF configurations can reduce throughput by 37% and add 120ms to response times. But proper tuning brought that latency down to just 68ms while maintaining 94% of the security coverage.

Test environment and methodology

We built identical test environments to eliminate variables and focus purely on WAF performance impact:

Infrastructure specs:

  • CPU: 8-core Intel Xeon at 3.2GHz
  • RAM: 32GB DDR4
  • Storage: NVMe SSD
  • Network: 10Gbps dedicated
  • OS: Ubuntu 22.04 LTS
  • Web server: Nginx 1.22.1
  • WAF: ModSecurity 3.0.8 with OWASP Core Rule Set 3.3.4

Traffic simulation:
We used realistic e-commerce traffic patterns:

  • 70% GET requests (product pages, assets)
  • 20% POST requests (forms, API calls)
  • 10% complex queries (search, filters)
  • Request sizes: 1KB to 50KB
  • Response sizes: 5KB to 200KB
  • Load ramp: 100 to 2000 concurrent users

Configuration comparison results

Here's what we measured across five different WAF setups:

Configuration Throughput (req/s) P50 Latency P95 Latency Error Rate
No WAF (baseline) 3,420 28ms 45ms 0.02%
Default OWASP 2,140 56ms 120ms 0.08%
Tuned OWASP 2,890 35ms 68ms 0.04%
Minimal protection 3,180 31ms 52ms 0.03%
Full paranoia 980 145ms 340ms 0.15%

The tuned configuration delivered the sweet spot: 85% of baseline throughput while blocking the same attacks as heavier configurations.

Request type performance breakdown

Different request types showed varying sensitivity to WAF processing:

Simple GET requests:
- Baseline: 4,200 req/s
- Tuned OWASP: 3,500 req/s (83% of baseline)
- Full paranoia: 1,200 req/s (29% of baseline)

POST with form data:
- Baseline: 2,800 req/s  
- Tuned OWASP: 2,300 req/s (82% of baseline)
- Full paranoia: 750 req/s (27% of baseline)

Complex queries:
- Baseline: 2,200 req/s
- Tuned OWASP: 1,800 req/s (82% of baseline)
- Full paranoia: 520 req/s (24% of baseline)
Enter fullscreen mode Exit fullscreen mode

POST requests with large payloads suffered the most under strict rule evaluation, while simple GET requests maintained better performance across all configurations.

Infrastructure scaling implications

The performance numbers translate directly to infrastructure costs. For a site handling 100,000 daily visitors:

  • Tuned OWASP: 2 application servers (same as baseline)
  • Default OWASP: 3 application servers (+50% capacity)
  • Full paranoia: 7 application servers (+250% capacity)

Proper WAF tuning isn't just about performance; it's about infrastructure budget optimization.

Key optimization strategies that worked

1. Context-aware rule exclusions 

# Disable SQL injection rules for static content
SecRuleRemoveById 942100-942999 "REQUEST_URI:@beginsWith /static/"

# Skip file upload restrictions for APIs that don't handle uploads  
SecRuleRemoveById 200002 "REQUEST_URI:@beginsWith /api/data/"
Enter fullscreen mode Exit fullscreen mode

2. Anomaly threshold tuning

Raising the anomaly threshold from 5 to 8 eliminated 89% of false positives on legitimate complex requests without compromising attack detection.

3. Application-specific request limits 

# Adjust request size limits based on actual application needs
SecRequestBodyLimit 10485760  # 10MB for file upload endpoints
SecRequestBodyNoFilesLimit 131072  # 128KB for form data
Enter fullscreen mode Exit fullscreen mode

4. Geographic filtering

Blocking regions with no legitimate users reduced processing overhead by 12% for EU-focused applications.

Production deployment approach

Start minimal, expand gradually:

  1. Deploy with core protection rules only
  2. Monitor for false positives and performance impact
  3. Add rule categories based on actual threat patterns
  4. Tune thresholds based on application behavior

Essential monitoring metrics:

  • Request processing time by rule category
  • False positive rates by endpoint
  • Resource utilization during traffic spikes
  • Attack detection accuracy

Bottom line for developers

Proper WAF tuning can give you 94% of maximum security protection while maintaining 85% of baseline performance. Default configurations will hurt your application's responsiveness and increase infrastructure costs unnecessarily.

The key is understanding your application's specific patterns and tuning rules accordingly. Generic security configurations rarely optimize for your actual traffic and threat model.

For high-traffic applications, invest time in WAF performance testing before production deployment. The performance characteristics we measured would scale linearly with traffic volume, making optimization even more critical at enterprise scale.

Originally published on binadit.com

Top comments (0)