Automated scan on /wp-login.php, SQLi attempts on ?id=1' OR '1'='1, bots enumerating /wp-json/. Some bounce off CDN WAF with 403—the rest hit PHP because a custom plugin route matched no rule. The team thought they were WAF protected; they had reduced noise, not eliminated risk.
This scenario is frequent once an application firewall is enabled without prioritisation. WAF filters known signatures — SQL injection, reflected XSS, path traversal — but does not understand business logic. An authorised user can abuse a legitimate function; an unsigned zero-day passes until a rule recognises it.
A WAF (Web Application Firewall) inspects HTTP and applies rules before your application. It complements code—it does not replace prepared statements, business access control, or security updates.
What a WAF catches well
Known SQLi, XSS, path traversal signatures. Mass scans — volume, suspicious user-agents, doubtful geo. Bots — JS challenge, captcha, coupled rate limit — see small site DDoS. Temporary virtual patching — block rule for plugin CVE pending update.
| Layer | WAF | Secure code |
|---|---|---|
| SQL injection | Signatures + anomalies | Prepared statements |
| Reflected XSS | Pattern filtering | Output escaping |
| Business IDOR | No | Application authz |
| Malicious upload | Extension/MIME heuristic | Strict server validation |
WAF filters known noise. Business logic stays your responsibility.
Where to place the WAF
Edge CDN (Cloudflare, etc.) — filters before origin, absorbs volume; less body visibility with end-to-end TLS if terminate at edge.
Origin reverse proxy (ModSecurity + nginx) — fine control, local logs; you operate rules and updates.
Shared host — limited managed WAF; little custom rules.
Common hybrid: CDN for volumetric plus ModSecurity on sensitive admin routes. See also WAF or code fixes for prioritisation.
False positives: discipline
E-commerce cart, mobile API, rich editor POST — frequent triggers. Whitelist precise rule (URI + param), not disable security. Retest after major deploy. Correlate app logs — WAF 403 vs PHP 500.
Honest limits
Unsigned zero-day. End-to-end HTTPS without edge decrypt = limited inspection. False security delays plugin patches. Latency cost — heavy rules on every request.
The climax: WAF hides debt—until the missing rule
Position it as layer 2 after code hygiene and hardening — secure SSH, VPS firewall.
Decide and move forward without blind spots
Fix CMS and priority plugins first, then enable CDN WAF or ModSecurity in log mode, and tune documented false positives one by one. Couple rate limiting and 403 spike monitoring, and compare WAF offers via our directory while checking who operates rules and who responds when legitimate traffic is blocked.
Frequently asked questions
WAF or code fixes first?
Fix known vulnerabilities, then set WAF as safety net. WAF alone misses abused business logic and unsigned zero-days.
Shared hosting WAF vs Cloudflare?
Shared: often basic ModSecurity. CDN: managed OWASP rules, but proxied traffic—check GDPR impact.
How to handle false positives?
Log mode first, targeted whitelist, do not disable all OWASP in production.
Does WAF protect WordPress plugin flaws?
Sometimes on known patterns—not guaranteed. Updates and least privilege remain essential.
A WAF complements code like an airbag complements a seatbelt—it does not replace braking before the wall.