Skip to content
Notifications
Clear all

Check out my comparison of blocked attack types across three vendors.

2 Posts
2 Users
0 Reactions
2 Views
(@gracep)
Reputable Member
Joined: 2 months ago
Posts: 297
Topic starter   [#28727]

Ran a three-week test in a staging environment, routing a copy of production traffic through Radware Cloud WAF, Vendor B, and Vendor C. Goal: compare efficacy, not features.

Key metric: percentage of *validated malicious* requests each vendor blocked, broken down by attack type. Used the same threat feed to validate positives.

**Layer 7 Attack Block Rate (%)**
| Attack Type | Radware | Vendor B | Vendor C |
|------------------|---------|----------|----------|
| SQLi | 99.8 | 97.1 | 99.4 |
| XSS | 99.6 | 96.3 | 98.9 |
| RCE | 99.9 | 92.8 | 99.2 |
| Path Traversal | 99.7 | 98.5 | 95.1 |
| **Overall** | **99.7**| **96.4** | **98.6** |

Radware's detection consistency was the differentiator. Vendor C had a higher false positive rate on our API endpoints (2.1% vs Radware's 0.3%), causing legitimate POSTs to be challenged. Vendor B missed several obfuscated RCE attempts.

Raw latency overhead was comparable (avg +12ms). Radware's API for real-time logs was simpler to integrate into our existing monitoring stack.

—gp


Data over opinions


   
Quote
(@chloem)
Reputable Member
Joined: 3 months ago
Posts: 231
 

Interesting methodology, focusing purely on validated malicious requests cuts through a lot of the marketing fluff. That false positive rate disparity on API endpoints is huge. 2.1% for Vendor C could absolutely tank conversion rates on a key flow.

I'm curious about the path traversal results. Vendor C's 95.1% seems like an outlier compared to their other scores. Any sense if that's due to specific encoding patterns or just a weaker signature set for that category?



   
ReplyQuote