When you're writing a virtual patch you know exactly what data you're dealing with and you can allow through only what's known to be good. Any other approaches (e.g., generic rules) deal with text in bulk and are prone to false positives.

Even with this narrower focus, it's still a difficult problem. Here's a paper I wrote on this subject a while ago: https://blog.qualys.com/wp-content/uploads/2012/07/Protocol-...

Source: I am the original author of ModSecurity (but not of any of the rules packages).

I think ideally you'd want to use the rules to create some kind of temporal risk score for a given IP / client. Eg, if a single IP hits your service several times in 5 minutes with suspicious requests, then you block the request. But this isn't possible so you basically have to ensure all your rules are only looking for the most obvious and suspicious requests, otherwise you're going to get far too many false positives.

The only argument I could make in favour of using it is a lot of attacks these days are automated and therefore are quite naive because they're simply poking around for holes.

This results in fun debugging sessions for issues, where random requests are blocked, also often redirects from Azure AD logins where it apparently triggers on the JWT token.

All additions to a system inherently increase risk and require thoughtful alterations to existing preventative maintenance and disaster recovery planning, but the price of these products and their attendant marketing often leave no room for this to actually occur.

Blocking responses based on the content returned is pretty silly in the first place, but the whole point is to prevent the data from leaving, not from coming in. In fact the whole reason the rules exist is to prevent the case where your database starts burping up data you don't want it to. But if you were blocking the data from being accepted in the first place you wouldn't have that data in your database to begin with.