What is virtual patching?

A rule describes the exploit rather than the flaw.

Somebody works out what a request exploiting the weakness looks like: a parameter carrying something it should not, a path reached in an order it should not be, an HTTP header or value longer or stranger than the code handles. A rule in front of the application matches that shape and refuses it, and the request never arrives at the code that would mishandle it.

Everything hangs on that word shape. The rule knows the exploit, not the defect, so it protects against the versions of the attack somebody anticipated. A variation that reaches the same flaw by a different shape is a different request, and the rule has no opinion about it.

The technique is genuinely useful and routinely misunderstood, in a way that has a cost.

What it buys is time. A fix has to be written, reviewed, tested, and deployed, and some applications cannot be changed quickly for reasons that have nothing to do with willingness: a vendor product, a release train, an integration that has to be re-certified. A rule can be in place in minutes and holds the door while the real work happens.

What it does not do is fix anything. The weakness is still there, still reachable by any route the rule does not describe, and still present in every copy of the application elsewhere. Anybody with a variation walks past it.

The dangerous mistake is treating it as done. A rule with no expiry becomes permanent, and the urgency behind the fix evaporates the moment the alerts stop. Rules put in place for this reason should carry a date and a reason, which is the same discipline exceptions need, covered under operations.

A second cost: a rule describing an exploit shape can match ordinary traffic that happens to look similar, so it needs the same watching as any other rule before it starts refusing requests, which is what rules sets out.

The scanners that find such weaknesses in the first place are covered under bots, and the other vocabulary in this glossary.