How CheeseWAF works
Traditional regex WAFs keep large signature libraries. They are expensive to maintain and easy to evade with encoding or wrapping.
Calling a large language model on every request adds network latency you cannot hide.
CheeseWAF splits the work.
Two planes
Data plane
The process that accepts HTTP, HTTPS, or HTTP/3 does this in order:
- IP, GeoIP, and client soft-fingerprint checks
- Bot challenge, rate limit, and waiting room
- Semantic analysis of decoded parameter values
- Reverse proxy to the configured upstream
This path must stay fast. It never waits on a remote model.
Control plane
The management listener hosts:
- the setup wizard at
/setup - the Web console
- the REST API under
/api - optional Prometheus metrics
Keep server.admin_public false unless you also enable TLS and restrict who can reach the port.
ALAP
After the client already has a response, CheeseWAF can enqueue:
- isolated hits that were blocked at paranoia 5
- embedded hits that were allowed at levels 2–4
- other borderline samples the engine marks for review
A worker calls the configured model. The operator (or auto-agree) then saves a lasting rule or dismisses the sample.
See ALAP and the review queue.
What ships together
| Piece | Role |
|---|---|
cheesewaf | Forwarding process. Default command is serve |
waf-cli | Same binary or a symlink. Default command is the TUI panel |
cheesewaf-gui | Loopback-only desktop controller on Windows and macOS |
| Web console | React UI served from the management plane |
| SQLite | Default store, CGO-free (modernc.org/sqlite) |
You do not need Redis, Nginx, or an external database to start.