Why “blocking everything” is not the same as being secure (and how RedShield proves it)

Aggressively-tuned Web Application Firewalls (WAFs) claim to provide peace of mind by rejecting anything that resembles malicious traffic. In practice that claim often frays the moment a real-world application goes live.  That’s because when WAFs start blocking legitimate traffic (ie generate false positives), those users - and the business - rightly get upset.  With so many new threats and vulnerabilities, security teams often find themselves building what can feel like an “infinite wall” that blocks every threat but inadvertently brings the business to a grinding halt.

Even the best-configured cloud WAF in a recent comparison (OpenAppSec, “Best WAF Solutions in 2024-2025: Real-World Comparison) managed a respectable-looking false-positive rate of 0.009 percent, yet it achieved that number only by detecting just 12 percent of genuine attacks (ie missing 88 percent of attacks).  An alternatively tuned WAF caught 97.5 percent of attacks but incorrectly blocked 54 percent of legitimate requests. For an application that serves ten million requests a month, the first profile still locks out 900 legitimate users every month, while the second turns away more than five million users.

Faced with the inevitable user support tickets, operations teams often lower the WAF “security slider”, disabling rules until the complaints stop. At that point many of the vulnerabilities that were supposedly mitigated are once again exposed, but nobody can easily tell which ones.​ The result is a familiar pattern: a noisy first week of deployment, weeks of tuning, and eventually an uneasy truce in which the comprehensiveness of security is traded off against the need to not upset legitimate users.

Fix first, then decide what to block

RedShield’s philosophy turns that sequence on its head. Rather than trying to predict and block every possible exploit string, the service concentrates on removing the vulnerability that makes the exploit dangerous. RedShield’s developers create in-flight security patches that sit inside RedShield’s reverse-proxy platform. An in-flight patch can rewrite a request, sanitise a response, harden a session token, enforce strong passwords, inject a CSRF token, throttle a brute-force login or perform any other runtime action necessary to neutralise the flaw, all without touching the application’s source code.​ Once the flaw is remediated with an in-flight patch, traffic that would have exploited it is harmless noise. That means RedShield can leave more WAF rule-sets enabled without generating support tickets, because the rules are now detecting behaviour that cannot succeed, because the vulnerability effectively no longer exists. RedShield’s expert-managed WAF still blocks obviously destructive payloads and enforces fair-use limits, but it no longer has to guess whether every suspicious pattern is a genuine threat to this application.

“You block less, therefore you protect less” - a common misconception

Security teams that test RedShield by replaying canned exploit suites sometimes notice that fewer requests are rejected outright compared with an aggressive WAF profile. At first glance that looks like a gap in coverage, yet a closer look tells a different story.

During a five-day client engagement conducted by RedShield, penetration testers identified seventeen distinct vulnerabilities in a high-value web application. A WAF could mitigate four of them, however the remaining 13 vulnerabilities could not be addressed by a WAF, requiring developer intervention. RedShield deployed in-flight patches for the remaining thirteen within the same week, achieving full mitigation without requiring any application code changes.​

Because the exploitable surface had been removed, the test harness no longer produced security events when it replayed the original payloads; nothing it sent could reach a vulnerable endpoint. The WAF’s block counter therefore fell, yet the objective security risk was demonstrably lower. Because of this, RedShield is able to provide comprehensive application security with a very low false-positive rate of typically less than 0.0002 percent - two errors per million blocked requests. This is an improvement of typically two orders of magnitude over tuned standalone WAFs. When legitimate users are almost never interrupted, security teams spend their time investigating real incidents instead of triaging ghost alarms.