UUSEC WAF: a reverse proxy firewall where the rule layer is Lua and nginx

A gateway in front of your origin, not a library

The architecture decision that explains almost everything else about this product is stated in the installation notes: UUSEC WAF adopts a cloud WAF reverse proxy mode and needs ports 80 and 443 by default. Traffic terminates at the WAF, gets inspected, and is then forwarded to the origin server whose IP you supply in the console.

That means it is not a drop-in module for nginx or Apache and it does not sit in the request path of your application code. It is a separate host that you point DNS at, which also means it needs its own certificate and its own address in front of everything you already run.

The repository description frames the scope as WAAP: web application and API protection, not only request filtering. The topic tags back that up with api-gateway, api-security, ddos, rasp, data-mask, modsecurity and owasp among others, which is the vocabulary of a full gateway product rather than a single-purpose filter. GitHub reports the language as Shell, which is an artifact of the installer dominating the tracked code, not a description of the runtime.

Four detection ideas rather than one signature list

The README organizes its capabilities around five claims, and the interesting ones are the ones beyond signature matching.

Semantic analysis is the headline. Four detection engines cover SQL injection, XSS, remote code execution and local file inclusion, backed by decoding passes that restore base64, JSON and form payloads so an attack cannot hide inside an encoding layer. The stated benefit is that an administrator does not maintain a large rule library to catch those four classes.

Anomaly detection is the other distinguishing feature. Rather than matching known attacks, it learns the shape of normal request parameters and builds a whitelist from them, with the claim that an unfamiliar pattern can be caught without a rule written for it. The realistic reading is that this reduces noise on parameter-heavy applications, and that it is a complement to signatures rather than a replacement, since the semantic engines are described as running alongside it.

Runtime instrumentation is the deepest layer. RASP is inserted into the Java JVM and the PHP Zend engine to track execution context, and HIPS works at the host layer to restrict process network access, process creation, file reads and writes, privilege escalation and buffer overflow attempts. Those two require cooperation from the application runtime and the host, which is why they are separated from the traffic layer in the README's three-layer description of traffic, system and runtime defense.

Lua rules that take effect without a restart

The rule engine section makes a specific claim that is worth testing against your own expectations: rules published in the management backend take effect immediately without a restart, and the README contrasts this with free WAF products such as ModSecurity.

Two rule styles are offered. There is a traditional mode aimed at ordinary users, and there is a Lua scripting layer for administrators who can program. The Lua path is built on nginx and LuaJIT, and the framing is that plugins can be written to extend the WAF beyond what traditional rules can express.

This is the feature that separates UUSEC from a pure signature product, and it is also the one that changes how you staff the role. With Lua you can write a rule for a business logic flaw in your own application that no generic engine will ever ship a signature for. The cost is that you now own the correctness and the performance of that code inside the request path.

A related capability sits alongside it: cache purging that supports regular expression matching on URL paths, which the README positions as more capable than the wildcard-only cache purge in nginx's commercial tier. That is a small thing to advertise and a real annoyance to hit when you run a CDN in front of a busy application.

Installing is one command and then five steps

The stated prerequisites are Docker CE 20.10.14 or newer and Docker Compose 2.0.0 or newer, with a note that if the automatic Docker install fails you should install the engine yourself. The installer itself is a single line:

sudo bash -c "$(curl -fsSL https://waf.uusec.com/installer.sh)"

Afterwards, container management goes through a shell script at a fixed path:

bash /opt/waf/manager.sh

That script handles starting, stopping, updating and uninstalling. The README asks for a pure Linux x86_64 server, which is worth taking literally: this is a packaged appliance, not a multi-architecture project.

The five setup steps after login are the ones to expect on any reverse proxy WAF. The console lives on port 4443 over HTTPS, with the username `admin` and the password `#Passw0rd`, and changing that password should be your first action. Then you add a site by giving a domain and an origin IP, add a certificate by uploading the certificate and key or letting it obtain and renew a Let's Encrypt certificate, repoint the domain's DNS A record at the WAF address, and finally confirm the site loads and that the HTTP response's server header reads uuWAF. That last check is the cheapest way to confirm traffic is actually flowing through the appliance rather than around it.

Limits live in the release notes

The Community Edition has a site cap, and the release history shows it moving. Version 7.2.5, published in August 2026, raised the maximum number of websites in the Community Edition from ten to sixteen. That is a small, concrete example of a free tier limit that can change in a patch release without much fanfare, which is worth remembering before you plan a multi-site deployment on it.

The same release patched two nginx CVEs, 2026-42533 and 2026-56434. For a gateway product that terminates every request, nginx patches are not housekeeping, and a release that bundles them is easier to reason about than one that leaves you tracking upstream advisories yourself.

Earlier releases are thinner. Version 7.2.4 fixed certificate update failures, which is the kind of bug that quietly turns into an expired certificate in production. Version 7.2.3 added a basic authentication plugin and fixed the IP threat intelligence plugin, which suggests the plugin system is the extension point to watch if you need something the core does not do.

The repository is not archived, carries 83 open issues, and was last pushed on 2026-09-06, with the latest release a little earlier in August. Licensing is BSD-2-Clause according to both GitHub and the LICENSE file at the root, which is permissive, though that covers the repository contents rather than the compiled appliance the installer fetches.

What you are trusting, and what you cannot check from here

Two things deserve a clear-eyed look before you put this in front of a production site.

The installer is a script fetched over the network and piped into a root shell. That is the common pattern for appliances and it is not automatically wrong, but it means the artifact you run is decided at the moment you run it, and the code that produces the running container is not in this repository. The repository tree holds `docker/`, `rules/`, `plugins/`, `rasp/` and a `geo-ip-firewall/` directory, which describes the shape of the product but is a fraction of what the installer actually deploys.

The second is performance evidence. The README has an effect evaluation section comparing UUSEC WAF Free and Pro against ModSecurity at level 1 and Cloudflare Free, and it labels the table for reference only. The table itself is not readable in the repository text, so the numbers cannot be checked from here and the header row is all that survives. Rather than guess at the figures, take them to the vendor site and ask what traffic shape they were measured on. A semantic engine that decodes payloads and a RASP hook inside the JVM both cost latency, and the ratio depends heavily on request size and application stack.

If you want an independent read, the same question applies to the HIPS and RASP claims: they describe system-level behavior that a repository listing can hint at but cannot verify. Install it somewhere isolated first, put your own traffic rules in place, and watch what it blocks before you trust it in front of anything you would mind losing.

Editorial conclusion

UUSEC WAF is best understood as an appliance you operate rather than a library you embed. The reverse proxy model buys you a single place for TLS, caching, rate limiting and blocking, and the Lua rule layer means genuine engineering tasks do not require waiting for a vendor rule update. The costs are equally concrete: you hand over ports 80 and 443 and a DNS change, you accept a default admin password that must be changed immediately, and the release notes show a Community Edition site cap that changed from ten to sixteen in a patch release. Read the comparison table on the vendor site before trusting any performance number, since the README's own table is not readable from the repository, and start with the free edition's limits in mind.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. Safe3/uusec-waf on GitHub