[JoeSpaghettio]

So there are a few issues with this, WAFs do have their uses, generally speaking yes rules based on regexes looking for sql injection are silly. But they do have their useses. For example tarrgeted blocking, https://confluence.atlassian.com/security/cve-2023-22515-pri... . While waiting for the patch, a WAF can quickly block all requests to the /setup endpoint.

I would also say that static analysis as a panacea for SQL Injection is laughable. SAST tools have a hard time finding sql injection in code. As they quickly loose track of user controlled data. They almost always create false positives / false negatives when Parameterised queries are used incorrectly. For example when user controlled data gets into the SQL query rather than the parameter of a paremeterised query. And that completely ignores SQL Injection attacks that do not occur within your code directly, but in libraries you are using.

[sebazzz]

> While waiting for the patch, a WAF can quickly block all requests to the /setup endpoint.

So can IIS request filtering or whatever exists in Nagios. Right on the webserver.

[JoeSpaghettio]

depends on the org. The appsec team, may not have access to the webserver in production atleast not quickly. But will have access to modify a WAF they own.

[wiml]

I suppose from that perspective WAFs exist simply because of Conway's law.

[threeseed]

Many applications these days don't have web servers in front of them.