No. Virtual patching lowers risk for a known vulnerability by blocking matching attacks in front of the app, but it does not fix the flaw. It suits a legacy web application as a stopgap with a review date, not as the end state.
What virtual patching is
OWASP describes it as a policy enforcement layer that detects and blocks matching exploitation attempts for a known vulnerability, without changing the vulnerable code. The layer is usually a web application firewall, a reverse proxy or a gateway.
The same guidance states the limits plainly. It reduces exposure only for the traffic it inspects and the attack variants its rules recognize. A test passing with one payload does not prove complete protection. Overly broad rules can block legitimate users. And the business should understand that it may not be a complete fix for the flaw.
Where it fits well
| Situation | Fit |
|---|---|
| Injection style flaw in a form parameter you can describe | Good |
| Vendor gone, source unavailable, app must stay online | Good as a bridge |
| Flaw in business logic, such as a missing authorization check | Poor |
| Traffic you cannot inspect, such as non-HTTP protocols | Not applicable |
| Flaw reachable from inside the network, bypassing the proxy | Weak |
OWASP notes the approach is best suited to injection issues, which matches this table.
A workable process
OWASP lays out phases that translate well to a legacy app.
- Prepare. Put the filtering layer in place before you need it, enable audit logging that redacts sensitive data, and agree an expedited approval path.
- Analyze. Confirm the layer can detect the flaw type. Record the CVE or internal identifier, affected versions and the triggering configuration.
- Write the rule. Prefer allow-list rules, which accept only expected input, over block-list rules that are faster but easier to evade. Avoid rules that match only the exact published payload.
- Test in log-only mode first. Check that normal workflows still pass and that attack variants are caught. Go back to analysis if evasions succeed.
- Follow up. Track the rule in change management, record rule IDs, review alert reports and reassess periodically.
Make sure the proxy cannot be bypassed
A virtual patch protects only the path through the proxy. Firewall the app so it accepts traffic from the proxy and nothing else. Check that internal users cannot reach the app by its old address. This is the most common hole.
Keep the real fix on the list
OWASP says code-level fixes and virtual patching are not mutually exclusive, and that the vendor or code fix should continue alongside the virtual patch. For a legacy app, that might mean replacing the module that has the flaw, moving to a supported version of the framework, or retiring the app. Put the end date in the exception.
Try it yourself
Click through it at your own pace, or open it full screen. Step through it to see how a finding is checked for exploitability before you decide how urgent a rule is.
Quick check
Does a WAF rule count as a compensating control?
It can, if it targets the specific risk, is enforced by the proxy, and you can show test evidence. It should carry an owner and a review date.
Should virtual patch rules be removed once the app is fixed?
Review them. OWASP notes teams often keep them for better logging, but unneeded rules add noise and false positives.
Sources
Last reviewed: 19 October 2026.
