Web Firewall

The 8G-style request filter — watch mode, blocking mode, the six categories it checks, and the log of what it caught.

The Web Firewall inspects every request for the patterns attacks are made of, and can refuse it before your application runs any code. It is off by default.

The Web Firewall screen with Protect this application off and a note recommending you start by watching

Turn it on in watch mode first

The firewall enabled, showing the mode choice (Just watch, don't block / Actually block) and the six category toggles, with a Fine-tuning disclosure at the bottom

Switching Protect this application on reveals two questions.

What should happen to a suspicious request?

Mode	Behaviour
Just watch, don't block	Nothing is refused. Matches are written to a log so you can check for mistakes first.
Actually block	Matching requests are refused immediately.

What it checks — six categories, all on by default:

Category	Catches
Bad search terms	Attack code hidden in the query string.
Bad web addresses	Requests for files and paths only attackers look for.
Bad visitors	Known scanners and attack tools by user agent.
Bad links	Traffic claiming to arrive from spam and malware sites.
Bad cookies	Tampered cookies used to slip code past your application.
Bad request types	Request methods and shapes a normal browser never uses.

"Bad visitors" blocks command-line tools too

The category description is explicit: it blocks "command-line tools and HTTP libraries such as curl and Go, so uptime monitors, scripts and webhooks sent that way are blocked too." If you poll your own site with curl, this is the toggle that will break it.

Read what it caught

Save in watch mode and leave it for a few days. The badge reads Watching only — "Suspicious requests are recorded, but still allowed through" — and a count appears under the mode choice.

The firewall in Watching only mode, with a Watching only badge and "4 requests would have been blocked so far"

A What it caught card lists the matches, newest first, with the method and path, the address, the time and the user agent:

The What it caught card listing four requests that would have been blocked — a path traversal attempt, an upload-directory PHP probe, a UNION SELECT query and a script tag in a search parameter

Read the list before you switch to blocking. What you are looking for is your own traffic in it — an admin URL, a webhook, a monitoring agent. That is the false positive you want to find now rather than after it starts returning 403 to a customer.

Switch to blocking

The firewall with Actually block selected and a Blocking badge, saying suspicious requests are refused

Pick Actually block and save. The badge turns Blocking.

Verified on a live application: with blocking on, a request with ?s=<script>alert(1)</script> is refused with 403 Forbidden, while a normal page request still returns 200.

Fine-tuning

The Fine-tuning section with "Let these through" and "Always block these" lists, each with an input to add an entry

Two escape hatches, for when a category is right in general and wrong for one path:

Let these through — a request whose path contains any of these skips every check. Only the path is matched, not the query string or the user agent. The panel asks for at least four characters and warns that "a common word switches the firewall off across much of your application".
Always block these — a request containing any of these words is refused even if no category catches it. xmlrpc.php is the canonical entry.

Limits

The firewall is per application, and so are its exceptions.
Watch mode is not protection. The badge colour says so on purpose.
On OpenLiteSpeed the settings still save, but nothing enforces them — the screen shows a warning when the application's web server cannot run the firewall.
Only watch mode writes the match log. In blocking mode there is no What it caught card; refused requests show up in the access log as 403s.