Web Application Firewall (WAF)¶
The WAF inspects requests to your website before they reach your application and blocks recognised attack patterns — injection attempts against databases or scripts, for instance. It uses the OWASP Core Rule Set, a widely used and maintained rule set.
Enabled per website
The WAF is inert at first. It only takes effect once you enable it for a website.
Enabling it¶
- Navigate to WAF
- Select the website
- Enable protection
- Choose the level
The level (paranoia level)¶
The rule set has four levels. The higher the level, the more kinds of attack are recognised — and the more likely something harmless is blocked by mistake.
| Level | Effect |
|---|---|
| 1 | Catches unambiguous attacks, very few false positives |
| 2 | Stricter, occasional false positives |
| 3 | Considerably stricter, false positives likely |
| 4 | Very strict, only sensible with careful tuning |
The highest level you may choose depends on your package. Level 1 is always available.
Start at level 1
Begin low and watch for a few days. Only raise the level once no false positives appear.
Watching instead of blocking¶
In detection mode the WAF records matches but blocks nothing. That is the safe way to try a higher level without shutting visitors out.
When something legitimate is blocked¶
Legitimate requests can trigger a rule — particularly forms with longer texts, page editors, or file uploads.
- Open the log view
- Find the entry from the time of the problem
- From the list of matched rules, add an exception for exactly that rule and that path
Protection stays in place for the rest of the website. An exception is targeted, not blanket.
Symptoms of a false positive
A form will not submit, an editor will not save, an upload breaks off — and the browser shows "403 Forbidden". Check the WAF log first in that case.
What the WAF does not do¶
It recognises attack patterns, not vulnerabilities. An outdated application stays vulnerable even with the WAF enabled. Keep your software current — see WordPress.