A common assumption is that a Web Application Firewall (WAF) should automatically block all traffic that appears even slightly suspicious - assuming this guarantees security. The idea is simple: if traffic resembles an attack, block it and stay safe. But in reality, this strategy quickly becomes problematic. Blocking legitimate users leads to frustration and negatively impacts business operations. A WAF designed to block anything suspicious might seem secure in theory, but in practice it often breaks applications and harms businesses. The goal shouldn't be to build a wall that blocks everything suspicious; it should be to build one that's intelligent enough to distinguish real threats from genuine users.

 

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.

From protect, to secure, to assure

RedShield packages this methodology as a managed cycle:

  • Protect - deploy a battle-tested baseline policy (WAF signatures and DDoS protection) that repels volumetric attacks, common injection patterns and bots on day one, while tolerating application changes.​

  • Secure - scan each application, digest penetration-test reports and craft/deploy in-flight security patches that neutralise discovered vulnerabilities in hours or days.

  • Assure - correlate live attack traffic with known vulnerabilities, report on what would have been exploitable, and retire in-flight patches if the development team later fixes the underlying code.​
  •  
  • Because in-flight patches are first deployed in a non-production path - typically a UAT flow mirrored through the proxy - they graduate to production without holding up release trains.​ That keeps security in step with modern CI/CD pipelines, instead of forcing developers to wait for multi-week WAF tuning windows.​

What this means for CISOs and security professionals

  • Measurable risk reduction - every exploitable finding is either fixed or contained; dashboards show exactly which CVEs are shielded and which are now obsolete.
  • Near-zero user disruption - an effective false-positive rate of typically less than 0.0002% means help-desk costs and reputational damage fall away.
  • Faster change cadence - In-flight patches are quickly deployed and can be easily retired when the application is patched, so security no longer dictates release schedules.
  • Lower total cost of ownership – expert staff, 24×7 monitoring and a mature DevSecOps process are bundled into a single outcome-based service, at a fraction of the cost - typically 20% - of recruiting equivalent in-house expertise.​

The quiet firewall

In information security, counting the number of things you block is easy; counting the breaches you prevent is harder. RedShield’s “Fix-First” model focuses on the latter, and does so in a way that helps ensure business continuity and a good user experience. 

By eliminating the conditions that make an attack effective, it removes both the exploit and the collateral damage that blunt-force blocking causes. The net effect is a quieter yet effective firewall, happier users, and - most importantly - a materially safer application stack.

Security teams that judge success by the volume of traffic rejected may need to adjust their dashboards. Chief Information Security Officers who judge success by exposure, resilience and business uptime will find the numbers compelling. Blocking every suspicious byte looks decisive, but fixing the gap in the armour is what keeps the arrows out.

Next article: The Hidden Economics of DDoS and Bot Attacks: How to Tip the Balance
All Knowledge base