Discouraging the use of web application firewalls

Original Article ↗ Hacker News Discussion ↗

Web application firewalls (WAFs) are criticized as expensive, latency-inducing tools that provide a false sense of security, are easy for determined attackers to bypass, and are often deployed mainly to satisfy compliance checkboxes like PCI-DSS or HIPAA. Commenters argue that secure design, parameterized queries, static analysis, and proper isolation of services usually offer better protection, and that poorly tuned WAFs can even introduce new vulnerabilities or break legitimate traffic. Others counter that WAFs still have a role as defense-in-depth: handling volumetric attacks, shielding legacy or third‑party apps, providing quick “virtual patches” for emerging threats, and filtering out large volumes of automated garbage traffic.

Compliance, Audits, and Checkbox Security

  • Many deployments exist mainly to satisfy PCI-DSS, HIPAA, or internal checklists; auditors often only verify that a WAF is present, not effective.
  • Several note that PCI-DSS allows alternatives (e.g., continuous DAST) but WAF+OWASP rules is often the easiest evidence to present.
  • This leads to “pretend WAFs” with minimal or no blocking rules, used purely to tick boxes.

Effectiveness, Bypass, and Scope

  • Critics argue regex/signature-based WAFs are trivially bypassed by modestly skilled attackers, especially generic cloud offerings.
  • Others counter that WAFs block real attacks in practice (e.g., SQL injection that slipped past code reviews and tools) and raise the bar by filtering drive‑by scans and obvious exploits.
  • Several emphasize WAFs are not a panacea but part of defense in depth; relying on them alone is dangerous.

Performance and Attack Surface

  • Some point to significant latency and throughput hits, especially with ModSecurity-style engines, and note that well-built apps can answer 404s faster than a WAF can inspect.
  • Concerns that WAFs themselves add a large, memory‑unsafe, internet‑facing codebase and new misconfiguration risks; in extreme cases they’ve been the breach vector.

Operational and Organizational Realities

  • Enterprise-grade WAFs (e.g., Imperva-class) can require substantial tuning, staffing, and ongoing rule care; many end up “set and forget.”
  • Others say cloud WAFs are easy enough to manage part‑time and useful for basic bot filtering, IP reputation, and L7 rate limiting.
  • AppSec teams often can change WAF rules faster than application or webserver configs, making WAFs attractive for “virtual patching” (e.g., Log4j payloads, blocking specific endpoints).

False Positives and User Impact

  • Multiple examples of legitimate traffic blocked: OpenID redirects, common words like “Union” in addresses, standard framework behaviors.
  • Heavy default rule sets (e.g., “enable everything”) are called out as particularly problematic and sometimes prompt insecure workarounds.

Alternatives and Complements

  • Strong emphasis on secure application design: parameterized SQL, static analysis, strict API typing, process isolation, least-privilege access.
  • Some suggest basic network-level blocking, IP denylists, and API gateways/front-end routers as simpler or more transparent alternatives or complements.