Just a few examples: https://github.com/frizb/Bypassing-Web-Application-Firewalls
WAFs definitely help. No WAF is perfect, but having an additional layer to make exploitation harder, and having a tool designed to block specific attacks (like when a new CVE is issued for a CMS) is powerful.
Not to mention that WAFs are a requirement in regulated industries. PCI mandates it. And your SOC2 + ISO auditors probably will ask about it too.
A good set of filters deters casual abusers and can amplify the signal from a skilled attack, but ultimately they tend to fail.
the major challenges i've seen with WAFs on that front are that users treat them (and often, any part of a security solution) as a panacea for general classes of problems, which they aren't. WAFs can provide excellent targeted defense ("this request looks like it's trying to exploit CVE-2020-4521 specifically, I should almost certainly block it") and very mediocre general defense ("this request kinda looks like it might be SQLi--block it?").
the latter suffers from the issues others have raised in adjacent comments: the WAF doesn't know if the defended application applies its own sanitization (it should, but for its function, the WAF assumes that upstream doesn't, and could be vulnerable) and/or if the request content is something that reasonably should include SQLi-like content. The Cloudflare WAF in particular, at least circa 2018, suffered from including a lot of OWASP project rules that could spot "naked" SQLi quite easily, but in doing so also triggered on a lot content where the appearance of SQLi was, in fact, normal usage of punctuation characters where they made sense in plain English prose--someone can and should legitimately use quotation marks in the course of writing a prose English comment, like I'm doing right now, along with an occasional semicolon or paren alongside quotes, because those same symbols have meaning and use in both SQL and English prose.
this leads to lots of fun user confusion scenarios, where someone on the sales side of thing says "yes! enable the WAF! more protection = more product value for you!", and some months after, someone on the support side says "sorry, but the WAF can also generate false positives on legit text content, or can miss legit malicious content if it's gift-wrapped effectively (a la the OP)".
that sort of nuance is really hard to understand for more naive users, who can't easily distinguish between "the WAF blocks things it can positively ID as threats", "the WAF blocks things it mistakenly identifies as a threat based on superficial similarity to actual threats", and "the WAF doesn't block things that are threats, but are crafted to avoid the WAF". Users just see ~WAF~, and unfortunately often see it as technological wizardry that does or should just work, because it's magic. It ain't, but communicating the nuances, to a general audience? That's damn hard, and has long been neglected across industry because it doesn't fit well into shiny marketing copy.
technical improvements are valuable, but they can only go so far--at some point, there's greater value in educational content that helps dispel the magic somewhat, so that users understand the shortcomings of any given tool and can spot when those shortcomings arise. Thankfully the whole Cloudflare TV project and other educational content does seem to be progressing, though im unfortunately too far removed from the day to day now to see how well it's succeeding :) optimism hat on, it is, and godspeed!
There are occasions though where WAFs can be somewhat useful, like where you need to secure a vendors webapp that you can't patch without them releasing a fix or trust, but for legacy or business reasons are required to run.
So some of us are forced to buy and implement these products regardless of effectiveness, and it is helpful to see how vendors respond I think.
https://www.google.com/amp/s/www.zdnet.com/google-amp/articl...
That applies to everything security related. "Don't review your source code for vulnerabilities, it may lull you into a false sense of security."
It's simply impossible to consistently recruit developers with good security knowledge, especially if we want, as an industry, to take responsibility for getting new developers up the first few rungs of the ladder.
And you do need a mechanism that can provide defense for legacy applications, or to quickly mitigate 0-days.
As long as we can't guarantee that developers won't screw up, we need tools for cyber-security to mitigate these attacks. WAFs and other layered security devices do fill that need.
However!
Any layered security device must be bypassable. Your WAF is probably configured by the same people who make the automated security tests your pen-testers run.
If your pen-testers aren't bypassing layered security and attacking your application directly, then you're not really doing layered security anymore. Your WAF's security becomes snake oil, and your application's security is untested.
At the end of the day, the red team always wins. Tactical risk mitigation, segmentation and logging are the way to address security. Best case, your monitoring detects and alerts on the guy attacking the WAF, otherwise you have logs to conduct an investigation later.
Perfect, exactly what most people lack.