A CVE alert hits your e-commerce plugin on a Tuesday. No patch for ten days. The host offers to enable the "full OWASP" WAF. You enable it: abandoned carts explode — rule too aggressive on a legitimate parameter. WAF disabled: the exploit returns. Patch Friday: problem solved in one line — the WAF was only a noisy bandage.
WAF = network filter in front of the application. Fix = removal of the vulnerability. Neither replaces the other. Facing a web flaw, the question is not "which to choose" but in what order and for how long.
WAF: reaction speed, bypass possible
Cloudflare, ModSecurity, OVH WAF or AWS — all inspect HTTP and block known signatures.
Strengths. Fast deployment, temporary absorption of mass scans, attack logs useful for prioritising the patch.
Limits. False positives on business logic, encoding bypasses, zero-days without existing rules, and above all: vulnerable code remains in place.
Code fix: durable, slower
Framework update, input sanitisation, prepared queries, removal of vulnerable plugin.
Strengths. The flaw disappears; you no longer depend on an external rule that can be bypassed or disabled by mistake.
Limits. Development and QA delay, regression risk, impossible to act in minutes on a zero-day.
| Situation | WAF first | Patch first |
|---|---|---|
| Active exploit, no patch | Yes (targeted) | Impossible |
| Patch available | Temporary | Yes |
| Checkout false positives | High risk | Preferable |
| Automated scan noise | WAF useful | Insufficient alone |
Recommended incident workflow
First confirm exploitability on your exact version — not just the generic CVE. Apply patch or workaround (feature disable, custom WAF rule in log-only mode). Test checkout and critical APIs before switching to block. Move to block mode only after twenty-four hours of clean logs. Remove the temporary rule once the patch is deployed and verified.
Infrastructure hardening: third layer
WAF and patch do not replace a reduced surface: firewall, automatic updates, staging/production separation, tested backups. See Seravo and WordPress security if your stack is CMS-based. The host may offer managed WAF — useful for noise, insufficient without application governance.
The peak: the WAF masks debt, it does not extinguish it
Decide and move forward without blind spots
Inventory plugins, CMS versions and dependencies; subscribe to CVE feeds for your stack. Choose a host WAF for automated noise, and plan custom rules if your business API cannot tolerate generic filters. Set an internal patch deadline under seventy-two hours for critical flaws. Test every WAF rule in staging before production blocking. Browse our guides and directory to compare host security offers.
Frequently asked questions
Does a WAF replace a security patch?
No. It filters known malicious requests; the flaw remains in code. Bypasses are frequent if no fix is published. A WAF is a network filter, not an application repair.
When should you enable a WAF in an emergency?
During a zero-day with no immediate patch, in a maintenance window or under active attack — always alongside a dated remediation plan. Never leave a WAF alone without a patch deadline.
Are managed host WAFs enough?
For automated noise, often yes. For fine business logic — checkout, API — false positives require custom rules and log-only testing before blocking.
Recommended priority order?
Fix or mitigate code first, then targeted WAF rule, infrastructure hardening and attempt monitoring. The reverse — generic WAF without patch — leaves debt open.
The WAF buys time; only the fix buys a quiet night — do not confuse the two.