Open source WAF: which web application firewall to pick

Three open source tools filter requests before they reach a web application, each in its own way. BunkerWeb replaces your reverse proxy and blocks whatever the OWASP Core Rule Set (CRS) flags, out of the box. CrowdSec starts from your logs and an IP blocklist shared among its users, and its WAF, in the basic setup, only blocks known vulnerabilities. open-appsec plugs into the proxy you already run and scores every request with trained models instead of signatures. You can mix them: BunkerWeb and open-appsec can both enforce CrowdSec's decisions.

OWASP rules, shared reputation or a trained model

BunkerWeb and CrowdSec's AppSec component both load the CRS, but they use it differently. BunkerWeb runs it inline, version 4 at paranoia level 1, the least strict of four: a request that trips a rule is refused. The basic deployment CrowdSec documents only blocks known vulnerabilities inline, through the virtual patching collection from its Hub, 190 rules that each target one CVE. The CRS comes on top out of band: the request goes through, but an IP that triggers it on more than five distinct requests within a short period gets banned.

Reputation doesn't wait for a suspicious request: an IP reported elsewhere is turned away on its first one. In CrowdSec, scenarios read logs, SSH as well as NGINX, and every engine that reports its alerts gets a community blocklist of malicious IPs back. BunkerWeb runs its own network, BunkerNet, on by default, which hands out the IPs blocked by other instances.

open-appsec, from Check Point, takes the trained-model route. A first model, trained offline, scores every request; if it looks suspicious, a second model, learned from the site's own traffic, weighs the URL and the users involved before deciding to block. The vendor's pitch is zero-day protection with no signatures to keep current and no exceptions to manage. Signatures come back in its IPS engine, though, which covers more than 2,800 web CVEs and is for paying customers only.

Where each tool plugs in

BunkerWeb is the reverse proxy itself: an NGINX server installed as a Linux package, as Docker containers, or as an Ingress controller on Kubernetes. Its autoconf service watches for new containers and Ingresses and reconfigures the instance without recreating it. Adopting it means swapping out the proxy you have.

CrowdSec keeps detection and blocking apart. The engine reads logs and stores its decisions in a local API, and bouncers enforce them in the firewall or the reverse proxy, on other machines if need be. The engine alone blocks nothing. For the WAF you need a bouncer that forwards requests to it: NGINX, OpenResty, Traefik, HAProxy or Envoy.

open-appsec goes inside the proxy already in place. A C module, the "attachment", plugs into NGINX, Kong, APISIX, Envoy or the Istio ingress gateway and hands requests to an agent over shared memory. On Linux, the installer picks a precompiled module for your server version; if yours is not on the list, you build it. The team also ships NGINX Proxy Manager images with the module built in.

The projects document how to combine them. BunkerWeb's CrowdSec plugin turns it into a bouncer that can also pass requests to the AppSec component, and its all-in-one image bundles a CrowdSec agent, off by default. open-appsec can block the addresses CrowdSec supplies, on Ingress NGINX or in Docker with NGINX or Kong, and a CrowdSec collection reads its logs in return to feed the community blocklist.

What each tool needs to run

Read from the repositories and documentation on 7 October 2026.

Outside the all-in-one image, BunkerWeb runs at least the NGINX instance and the scheduler, which stores the configuration in a database and renders it; on Kubernetes, several instances share a Redis or Valkey. CrowdSec recommends MySQL, MariaDB or PostgreSQL for a busy local API. Without a my.openappsec.io token, open-appsec's Compose file starts the agent, the patched NGINX, smartsync (which merges learning across instances), its storage, a tuning service and PostgreSQL 18. The agent shares the host's IPC namespace, and the example pulls the latest image. None of the three gives a memory figure in its docs.

Before you block: detect-only modes and false positives

BunkerWeb has a detect mode that logs without blocking, and its defaults are a good reason to use it: 2 requests per second per IP and per URL, and a 24-hour ban for any client that gets 10 HTTP errors within 60 seconds. Its README "strongly recommends" tuning those values. CRS false positives are fixed with configuration files loaded before or after the rules, and the paranoia level is raised the same way.

open-appsec starts in Learn/Detect mode. With enough traffic, learning takes "about 2-3 days", and the docs recommend switching to Prevent once the engine reaches "Graduate", the third of five levels.

CrowdSec's documentation rates false positives from its virtual patching rules as minimal, since they only target known vulnerabilities. It warns, on the other hand, that running the CRS inline may take some tuning to keep them down.

What each instance sends and gets back

BunkerNet is on by default. It registers the BunkerWeb instance with api.bunkerweb.io, reports every blocked IP along with the reason and minimal context, and downloads the shared list. USE_BUNKERNET=no turns it off. BunkerNet is also required to enroll an instance in CrowdSec's console, under a partnership Bunkerity advertises.

CrowdSec sends its central API, for each alert, the scenario name and version, a timestamp, the machine ID and the offending IP, never the logs themselves. What you get back depends on that contribution: 15,000 IPs for an instance that reports signals regularly, 3,000 in the Lite version served to the rest. The docs give two reasons an engine lands on Lite: self-hosted services used by a small circle, and setups already locked behind a VPN, geoblocking or OAuth.

open-appsec's documentation mentions no list shared between its users. Its smartsync service pools learning across the instances of one deployment, and the CrowdSec collection is what carries its logs out to a community blocklist.

What the paid editions keep for themselves

BunkerWeb keeps nineteen modules for its PRO version, among them OpenID Connect, SAML and LDAP authentication in front of your apps, the Prometheus exporter, anti-DDoS and multi-user management in the web UI. The pricing page lists €49 a month for Shield and €149 for Fortress, and the licence needs outbound access to api.bunkerweb.io. The free version is AGPL-3.0: anyone who runs a modified version as a network service must publish its source.

CrowdSec's engine, its Hub and its official firewall, NGINX and HAProxy bouncers are MIT licensed. Premium is billed per enrolled engine with no published price, and adds decision sync across instances, centralized allowlists, up to a year of history and a 60,000-IP blocklist with no contribution required. The free console stops at 500 alerts a month over two months of history.

open-appsec's repository is Apache-2.0, "basic" model included, but the README recommends that model for testing and monitor-only setups. The "advanced" model, recommended for production, is downloaded from the vendor's portal after logging in, under its own licence. Anti-bot, API schema enforcement, file security and IPS require a subscription to Check Point WAF, the enterprise edition, or to Premium Edition. The docs mark Premium "deprecated", yet the pricing page still sells it at $79 to $109 a month. In the community edition, rate limiting accepts a single rule.

Where the projects stand

BunkerWeb's repository dates back to 2019; it has shipped nine stable releases since January 2026, and 1.6.16 is at its fourth release candidate. Its Swarm integration is deprecated, and Gateway API mode on Kubernetes is still in beta. CrowdSec shipped six stable releases in 2026, against eleven in 2025; 1.8.0, in late August, fixed two denial-of-service vulnerabilities and brought in bot detection that is still alpha. open-appsec has published four releases in 2026, against ten in 2025, and its main branch has 10 commits this year, one of them a 216-file drop. The notes for its last three releases come down to support for new NGINX versions and Linux distributions, plus bug fixes. The third-party code audit its README cites dates from 2022.