FAQ

FAQ

Which files am I supposed to include?

For Nginx, only the two aggregate files: waf_maps.conf in the http block and waf_rules.conf in the server block. The per-category files are inputs to those, not include targets, and including them directly produces the "directive is not allowed here" errors described in Troubleshooting Nginx. For the other backends, follow the integration guides.

Does this work with Caddy?

Not through this project. Caddy has its own, separate implementation: caddy-waf. The Caddy importer that used to live here was removed; issues about it in the tracker predate that split.

Will it block Google and other search engines?

No. The bad-bot list targets SEO crawlers, AI training bots and known scanners, and explicitly allows the major search engines: Google, Bing, DuckDuckGo, Yandex and Baidu. If you want a stricter or looser policy, edit the generated blocklist or the source lists in badbots.py.

How often are the rules updated?

Daily at 00:00 UTC. The workflow re-fetches the upstream Core Rule Set, regenerates every backend and republishes the release. There is only one tag, latest, and it moves, so record the SHA-256 of the archive you deployed if you need a reproducible deployment.

Do I need to build anything?

No. Pre-built archives are attached to every release: nginx_waf.zip, apache_waf.zip, traefik_waf.zip, haproxy_waf.zip. Building from source is for customising the output or adding a platform, and needs Python 3.9 or newer.

Is this the same protection as ModSecurity with CRS?

The rule source is the same upstream Core Rule Set, and coverage spans SQL injection, XSS, RCE, LFI, RFI and protocol violations. The enforcement is not the same: on Apache the output is real SecRule directives for ModSecurity, while on Nginx, Traefik and HAProxy it is native pattern matching without a ModSecurity engine. Treat it as strong pattern-based filtering, not as a drop-in ModSecurity replacement.

I patched a file under waf_patterns/ and my change disappeared

That directory holds generated output and is rebuilt by the daily workflow. Changes belong in the converter that produces the file, json2nginx.py and its siblings, or upstream in owasp2json.py when the problem affects every backend.

Something does not parse. Is it me?

Possibly not. Check the open issues first: the known Nginx parsing bugs are listed in Troubleshooting Nginx, and that list is kept against the tracker. If yours is not among them, open a new issue with the full nginx -t or haproxy -c output and the release you are running.

Which Core Rule Set version am I running?

Not necessarily the one named in the release notes. The notes query the CRS latest release separately from the code that fetches the rules, and the fetcher resolves a tag prefix rather than an exact tag. How it works explains how to check, and how to build against a version you choose with --ref.