A network firewall decides which ports are open. A web application firewall looks inside the traffic on the ports that are open — the HTTP requests — and blocks the ones that look like attacks: SQL injection in a query string, a script tag in a comment field, a request for /wp-config.php.bak. It is a filter between the internet and your application.
What a WAF stops
- Injection attacks — SQL, command, LDAP injection patterns in parameters.
- Cross-site scripting —
<script>and event-handler payloads in form input. - Path traversal and file inclusion —
../../etc/passwd, remote URLs in include parameters. - Known exploit signatures — requests matching public exploits for popular plugins, often before the plugin author has released a fix.
- Bad bots and scanners — tools that probe every site for a list of vulnerabilities.
- Rate-based abuse — hundreds of login attempts or form submissions a minute from one source.
The value is that it protects you from vulnerabilities you do not know you have. A WordPress site with an outdated plugin is still exploitable, but the exploit request has to get past the WAF first.
What it does not stop
- Logic flaws specific to your application (a price you can change in the checkout form).
- Attacks over channels the WAF does not see: SSH, FTP, a compromised admin password used normally.
- Malware already on the server.
- Anything novel enough not to match a rule, if the WAF is rule-based only.
A WAF is one layer. Updates, strong authentication, backups and scanning are the others; see the WordPress hardening checklist.
The options
ModSecurity on the server — the open-source WAF that runs inside Apache or Nginx. Plesk bundles it under Tools & Settings → Web Application Firewall (ModSecurity) with a choice of rule sets: the free OWASP Core Rule Set, or Comodo's, or Atomicorp's commercial set. Turn it on in Detection only first, watch the log for a week, then switch to On.
Imunify360 — commercial, server-side, combines WAF, malware scanning, IP reputation and a proactive PHP defence. Included on VPSPioneer shared and reseller plans.
Cloudflare — a cloud WAF: DNS points at Cloudflare, traffic passes through it, attacks are filtered before reaching your server. The free plan includes basic managed rules and rate limiting; the Pro plan (about £20/month) adds the full OWASP set and more. Also absorbs DDoS traffic, which a server-side WAF cannot.
Plugin WAFs (Wordfence, Sucuri) — run inside WordPress. Convenient, but the request has already reached PHP by the time they see it, so they cost CPU and cannot protect against attacks on the server itself. Fine as an extra layer; not a substitute.
False positives
Every WAF occasionally blocks a legitimate request — a form with SQL in it because someone is a database consultant, a page builder saving HTML, an API call with unusual encoding. The signs: a 403 on save in the WordPress editor, a contact form that "does nothing" for some users. In Plesk, the ModSecurity log (Logs, filter by ModSecurity) shows the rule ID; you can switch off that one rule for that domain under Web Application Firewall → Settings → Switch off security rules.
Do you need one?
| Site | Recommendation |
|---|---|
| WordPress with plugins | Yes — server-side (ModSecurity or Imunify360) at minimum |
| Any site with a login or forms | Yes |
| E-commerce | Yes, plus Cloudflare for DDoS |
| Static site | No; nothing to attack |
| Custom application with public API | Yes, in detection mode until the rules are tuned to it |
The cost is near zero (ModSecurity is free and included), and the log alone is worth having: it shows you what is being tried against your site every day.
Turning it on in Plesk
- Tools & Settings → Web Application Firewall (ModSecurity).
- Mode: Detection only to start.
- Rule set: OWASP (free) or Comodo (free, fewer false positives on WordPress).
- After a week of reading the log: switch to On.
Per domain, the toggle is under Web Application Firewall on the domain card, so a site with a problematic app can be excluded without turning it off for everyone else.
On VPSPioneer shared plans Imunify360's WAF is on for every site; on a managed VPS we enable ModSecurity with a tuned rule set at setup, and for stores or sites that have been attacked before we put Cloudflare in front as well — the setup is part of our website security service.