By Philippe Humeau, CEO and co-founder of CrowdSec
We’ve written a WAF before. Back in the NBS System days, two of us, Thibault and Seb, wrote NAXSI, an nginx module that blocked attacks without a single signature. It protected a lot of websites for a lot of years, and we’re still a bit proud of it (the learning mode, less so: anyone who ran NAXSI in production remembers the whitelists 😅).
So when we started the CrowdSec WAF, we’d already been through “how do we write a WAF engine?”. The question this time was simpler: what actually stops the bad guys? The honest answer: the engine is the easy part. Parsing HTTP and matching rules is a solved problem. What makes a WAF protect you is the rules it runs, how fast they arrive when a new CVE is exploited, and what it learns from everyone else’s traffic.
Then there’s the fear every WAF owner knows: blocking a paying customer. One false positive on a checkout page and the WAF goes into detection-only mode “for now”, where it often stays for years, producing alerts nobody reads. So the other half of the answer is rules that block what attackers send without touching what your users send.
That’s the lens we use to compare the open-source WAFs people ask us about (and a couple of commercial ones, while we’re at it).
The short version
| Engine | License | OWASP CRS | Virtual patches for exploited CVEs | Learns from other users | Best for | |
|---|---|---|---|---|---|---|
| CrowdSec WAF | Coraza-based (our fork) | MIT | Yes | Yes, from live exploitation data | Yes: the network blocklist | Protecting several proxies with one brain |
| ModSecurity | libmodsecurity (v3) | Apache 2.0 | Yes (its home) | Write your own | No | Existing deployments, until you migrate |
| NAXSI | nginx module | GPL-3.0 | No (own model) | No | No | Legacy nginx setups |
| Coraza | Go library | Apache 2.0 | Yes | Write your own | No | Developers embedding a WAF engine |
| open-appsec | ML engine (Check Point) | Apache 2.0, model under its own license | Not its model | Model-based | Via Check Point’s model updates | Check Point environments |
| BunkerWeb | nginx + ModSecurity | AGPL-3.0, PRO and Cloud editions | Yes | Via plugins | With the CrowdSec plugin | A WAF that is also your web server, or fully managed |
| UBIKA | Proprietary | Commercial | n/a | Vendor-managed | Vendor-managed | Enterprise appliance buyers |
(Licenses and features from each project’s own pages, read 19 October 2026.)
ModSecurity: alive at OWASP, and showing its age
ModSecurity started in 2002, as an Apache module, and for two decades it was the open-source WAF. Most of what we know about WAF rules comes from it, through the OWASP Core Rule Set.
Then came 2024. Trustwave, which had maintained it for years, ended its commercial support on 1 July 2024, and F5 retired its NGINX ModSecurity WAF module the same year. That ended the commercial backing, not the project: ModSecurity moved to the OWASP Foundation in January 2024 and keeps shipping releases, and we respect the people who keep it going.
Can you run ModSecurity in 2026? Sure. Would we start a new deployment on it? Not today. Its rules live in each web server’s config, so ten proxies mean ten configs to babysit, and its commercial sponsor has moved on. The good news: the most valuable part of ModSecurity, the Core Rule Set, isn’t going anywhere, and the CrowdSec WAF runs it. Migrating means keeping your CRS rules and changing what runs them.
NAXSI: we wrote it, and we rebuilt for good reasons
NAXSI took the opposite road to ModSecurity: instead of signatures, it scored requests on suspicious characters and patterns, and you whitelisted what your application legitimately needs. It was fast, and it had no signature list to maintain.
So why didn’t we just bring NAXSI into CrowdSec?
- It lives inside nginx. Today’s stacks run Traefik, HAProxy, Envoy, Caddy and Kubernetes ingresses, often several at once.
- Every application needs its own whitelist. A learning phase per app works for a careful team with a handful of sites. It doesn’t scale to hundreds, and even less now that apps change every week, with AI-assisted development shipping new forms and endpoints faster than anyone can whitelist them.
- It only knows what one server sees. NAXSI can’t tell that the IP probing you right now has been hitting other people’s servers all morning.
The original repository was archived in November 2023 (a community fork carries on). The idea survived, though: blocking should be cheap and precise. We moved it to a place where it can learn from more than one server.
Coraza: a great engine, and we build on it
Coraza is the modern answer to ModSecurity’s engine: an OWASP project, written in Go, compatible with ModSecurity’s rule language and the Core Rule Set. It’s the engine we chose.
The CrowdSec WAF runs on our fork of Coraza, and we send fixes back upstream (Seb’s merged contributions include a raw body processor and an uppercase transformation). No war here: if you want to embed a WAF engine in your own Go application, use Coraza.
What we add is everything around the engine, the part that actually raises your security:
- Virtual patching rules for exploited CVEs, written by our team and prioritized by what our Live Exploit Tracker sees attackers exploiting right now.
- One engine for all your proxies. Nginx, OpenResty, Traefik, HAProxy, Envoy Gateway and WordPress forward requests to the same CrowdSec instance: update a rule once, every proxy gets it.
- The network effect. What your WAF catches becomes a signal for the network, and what more than 300,000 active Security Engines catch reaches your WAF as a blocklist. The scanner looking for your WordPress plugin can be banned before its first request reaches you.
- Behaviour on top of requests. WAF hits feed CrowdSec scenarios, so an IP that trips a few rules gets banned on every server, instead of being refused once.
- Bot detection with a browser challenge, in the same component.
In layman’s terms: Coraza on steroids, and collaborative.
open-appsec: open source, with an asterisk
open-appsec, from Check Point, takes a machine-learning approach: instead of rules, a model learns what normal traffic looks like for your application. We’re partners, and CrowdSec integrates with it.
Its code and a basic model are Apache 2.0. The advanced model, the one its documentation recommends for production, comes from Check Point’s portal under its own model license (hence the asterisk). That’s a reasonable choice for a vendor, and a good fit if you’re already a Check Point shop. For most teams, though, a learning period per application and a vendor portal for the production model is more machinery than they want. Rules you can read, plus a network that has already seen the attack, get you protected on day one.
BunkerWeb: a different approach, and a partner
BunkerWeb, also built in France, is a web server and a WAF in one: nginx under the hood, ModSecurity and the Core Rule Set inside, AGPL-3.0, with a PRO edition and a fully managed BunkerWeb Cloud. You put it in front of your services, or let them run it for you.
CrowdSec plugs into the proxies you already run, instead of replacing them. Different approaches, and they combine well: BunkerWeb integrates CrowdSec, so a BunkerWeb user gets the network blocklist too.
UBIKA: the enterprise appliance route
UBIKA (formerly DenyAll, then part of Rohde & Schwarz Cybersecurity, now owned by TSS) sells a commercial WAAP, as a gateway or in the cloud, to large organizations. It’s proprietary, priced for enterprise procurement, and its rules and threat data are the vendor’s.
If you’re choosing a French WAF, there’s another option: the CrowdSec WAF is open source (MIT), runs on your own proxies, and is backed by threat data from the whole network instead of one vendor’s customer base.
When CrowdSec WAF isn’t the right pick
Is it for everyone? No. If you want zero infrastructure and someone else running the WAF end to end, a managed service (BunkerWeb Cloud, a CDN WAF) is simpler. If you have no reverse proxy at all, start there. And like every WAF running the Core Rule Set at high paranoia levels, you’ll spend some time on false positives: our virtual patching rules are built to avoid that, the generic CRS rules less so.
Getting started
- Pick your proxy in the AppSec quick start guides: Nginx, OpenResty, Traefik, HAProxy, Envoy Gateway, Kubernetes ingress, WordPress.
- Prefer a walk-through? Open-source WAF for Nginx on Ubuntu with CrowdSec takes about 15 minutes.
- Coming from ModSecurity? Keep your CRS rules: CRS support in CrowdSec.
Struggling with a rule or a migration? Hop onto our Discord and tell us what you’re running: that’s also how the next virtual patches get prioritized.
FAQ
Is ModSecurity dead? Not quite: it’s retired from commercial support. Trustwave ended support on 1 July 2024 and the project is now run by OWASP volunteers. Its Core Rule Set is very much alive, and runs on other engines such as Coraza and CrowdSec.
Is the CrowdSec WAF based on ModSecurity? It’s based on Coraza, a modern Go engine compatible with ModSecurity’s rule language, so it runs the OWASP Core Rule Set and existing ModSecurity-style rules.
What’s the best open-source WAF in 2026? For a single nginx server, any CRS-based WAF will do. For several proxies, or if you want protection from attacks seen elsewhere before they reach you, the CrowdSec WAF adds virtual patching and a network blocklist on top of the engine.
Is the CrowdSec WAF free? Yes, it’s open source (MIT) and part of the free CrowdSec Security Engine. Paid plans add premium blocklists and Console features.
