Deploying a Web Application Firewall: Modes, Sizing and a 4-Week Pilot

Most web application firewall projects I review fail in the same quiet way. The appliance is installed, everyone feels safer, and two years later it is still in report-only mode. In one recent review, every attempt to turn on blocking had broken the customer login form, and enabling HTTPS inspection pushed the CPU to its ceiling. The product was fine. The decisions made before deployment were not.

Here is the engineering checklist I now use before any WAF goes into production.

Decide the deployment mode first

• Reverse proxy gives full control: TLS termination, bot and Layer 7 DoS defense, response rewriting. For business-critical applications, this is the target.
• Transparent or bridge mode avoids address changes, but some features are limited and decryption needs the server's certificate and key.
• Offline monitoring carries no outage risk, but it is an evaluation stage, not protection.

Size by requests and handshakes, not bandwidth

Measure four numbers from your web server or load balancer logs: peak requests per second, new TLS connections per second (RSA versus ECDSA changes this dramatically), throughput with a realistic policy rather than the datasheet's simple one, and growth for the next two years with 30 to 40 percent headroom. If the application is critical, plan for a second node and high availability from day one.

Akamai's State of the Internet research counted 311 billion web application attacks in 2024, a 33 percent increase over the previous year, with APIs as the primary target. That volume is why sizing errors show up quickly.

Features worth testing, not just reading about

• Automatic policy learning, so the WAF models normal behavior instead of relying on signatures alone
• OpenAPI or Swagger import to reject requests that do not match the API definition
• Bot and credential stuffing detection on login and sign-up forms
• A way to turn scanner findings into narrow virtual patches
• Detailed logs to your SIEM and per-parameter exceptions for false positives

Run a four-week pilot

Week one, deploy in report-only mode in front of one real application. Week two, let it learn and scan the application with a web vulnerability scanner. Week three, fix false positives and measure CPU at peak hour. Week four, enable blocking and track stopped attacks, user complaints and team hours. Finally, close every path around the WAF: if the origin server or an old subdomain is reachable directly, attackers will simply skip it.

The full guide, with deployment and option comparison tables and the five most common mistakes, is here: https://symantecland.com/enterprise-waf-buyers-guide-f5-fortiweb-dptech/?utm_source=hashnode&utm_medium=article&utm_campaign=sx_syndication

— Kazem Mortazavi, independent network-security consultant