Open Source WAF
A web application firewall lives in an uncomfortable spot: too loose and injection attempts walk through, too strict and you are turning away real customers, and you usually learn which mistake you made from production traffic. That tension makes the rule engine, and your ability to read and tune it, the whole game. Open source WAFs put the detection logic in the open, so the decisions about what counts as an attack stay yours instead of hiding inside a vendor's black box. You can run the same rules in audit-only mode first, trace exactly which rule matched which part of a request, and keep policy in version control beside the rest of your infrastructure. The cost is that the request path, and its tuning, is now yours to operate.
SafeLine
Self-hosted WAF and reverse proxy for blocking web attacks, bots, and abusive HTTP traffic
BunkerWeb
Open-source web application firewall with reverse proxy support, web UI, and plugin-based security tuning
ModSecurity
Open source web application firewall engine for Apache, IIS, and Nginx
OWASP Coraza
Go-based Web Application Firewall library with ModSecurity SecLang and OWASP CRS v4 compatibility
NAXSI
Open-source NGINX WAF with simple rules and auto-learning whitelist support
Our picks
Pick by how the WAF meets your stack.
Best turnkey reverse-proxy WAF: SafeLine SafeLine sits in front of your apps as a reverse proxy and installs with a single command. It blocks SQL injection, XSS, RCE, SSRF, and path traversal, rate-limits abusive IPs against brute force and floods, and screens visitors with anti-bot and authentication challenges. The fastest path to protection without assembling an engine yourself.
Best batteries-included web server: BunkerWeb BunkerWeb is a secure-by-default, NGINX-based web server that runs as a reverse proxy on Linux, Docker, Swarm, or Kubernetes. It bundles a ModSecurity WAF with the OWASP Core Rule Set alongside Let's Encrypt HTTPS, TLS hardening, bot challenges, and IP blacklists, managed through an optional web UI.
Best positive-security module for NGINX: NAXSI NAXSI is an NGINX module that drops requests by default and allows only what your whitelist permits, so no unknown signature slips past it. Its rules are small and readable, and an auto-learning phase can build the whitelist from your own traffic. A lean firewall for teams already on NGINX.
Best embeddable engine for Go and proxies: OWASP Coraza OWASP Coraza is a Go WAF library compatible with the OWASP Core Rule Set v4 that reads ModSecurity SecLang rules. Embed it as middleware in a Go program or wire it into Caddy, Envoy, HAProxy, or nginx. The pick when you want CRS-grade rules under your own application's control.
Placing and tuning an open source WAF
Placement is the first fork in the road. A module inside the web server, like NAXSI in NGINX or ModSecurity behind Apache, IIS, or Nginx connectors, sees traffic close to the app and reuses native request state, but it ties policy to that server family. A reverse proxy such as SafeLine or BunkerWeb centralizes protection across services at the cost of another hop to scale and observe. A library like OWASP Coraza embeds the engine directly into a Go program or proxy. Decide fail-open versus fail-closed before production too, because that choice shapes outage behavior as much as security.
Then judge the detection model. Signature and rule sets such as the OWASP Core Rule Set, which BunkerWeb bundles through ModSecurity and Coraza implements natively, catch known payloads but generate noise on modern apps full of nested JSON, uploads, and GraphQL. NAXSI takes the opposite approach, a drop-by-default model with a small readable rule set and an auto-learning phase that builds a whitelist from your own traffic, so it cannot be bypassed by an unknown signature. Scoring models soften single-rule panic; strict positive-security policies work for narrow APIs where you can define every expected method and parameter.
Treat operations as part of the product. A workable WAF needs versioned policy, staged rollout, an audit-only mode, and logs that name exactly which variable matched which rule, so security can investigate and app teams can request narrow exceptions. Check how rules move through CI, how TLS certificates and secrets are handled, and whether metrics expose block rates, anomaly scores, and latency. Without that loop the WAF becomes shelfware or a production hazard.
Related categories
Frequently asked questions
What can an open source WAF actually block, and what does it miss?+
A WAF inspects HTTP requests before they reach your app and can stop many commodity payloads: SQL injection, cross-site scripting, path traversal, command injection, malicious uploads, and scanner traffic. Coverage depends on encodings and how well it parses request bodies. It will not fix vulnerable code, and it is weak against authorization flaws, workflow abuse, and account takeover with valid credentials. Treat it as a control that buys time for remediation, not a replacement for secure development.
How much tuning is realistic before I switch on blocking mode?+
Plan to run in audit-only mode against real production traffic first, not just synthetic tests. Review the high-volume rule hits, separate scanner probes from legitimate users, and write narrow exceptions tied to a path, method, parameter, or rule ID. NAXSI's auto-learning phase can seed a whitelist from your own traffic to shorten this. Blocking everything on day one is risky; start with high-confidence categories and widen coverage as false positives are understood.
Signature-based or positive-security: which detection model fits?+
Signature and CRS-style rule sets, as used by ModSecurity, BunkerWeb, and Coraza, catch known attack patterns but create noise on apps with nested JSON, uploads, or GraphQL. A positive-security model like NAXSI drops everything by default and only allows what your whitelist permits, so an unknown payload cannot slip past a missing signature, at the cost of more upfront learning. Narrow, stable APIs suit positive security; broad, changing apps often start with a scored rule set.
Does a WAF need to see decrypted TLS traffic?+
Yes. To inspect headers, paths, query strings, and bodies the WAF has to work on cleartext HTTP, which means terminating TLS at the WAF or placing it right after a trusted terminator that forwards decrypted traffic over a protected network. Reverse-proxy WAFs like SafeLine and BunkerWeb handle termination themselves, and BunkerWeb even automates certificates with Let's Encrypt. If client certificates or original protocol details matter to the app, confirm the WAF preserves and forwards that context.
How do these WAFs handle APIs and GraphQL?+
It comes down to how well the engine parses structured bodies and applies rules to specific fields. REST is easier when methods, paths, and content types are stable. GraphQL is harder because many operations share one endpoint and live in the request body, so look for request body limits, predictable JSON parsing, and a way to exempt expected query shapes without disabling inspection globally. A native SecLang engine like Coraza gives you field-level rules to do that.
Is self-hosting a WAF a good idea for internet-facing apps?+
It works well when you already run reliable edge infrastructure and have people to tune rules, watch alerts, and patch quickly. It is a poor fit if nobody owns 24-hour incident response, TLS renewals, or emergency rule changes, because the WAF sits directly in the request path. SafeLine and BunkerWeb lower the entry cost with single-command or containerized installs, but operational maturity matters as much as detection quality once you are live.
What happens if the WAF project stalls or stops getting security fixes?+
This risk is sharper for a WAF than for most software, because the engine itself parses hostile input, so an unpatched parser bug is a live exposure. Separate your dependence on the engine from your rule content: prefer a documented rule syntax you can move. Coraza and BunkerWeb both build on the portable OWASP Core Rule Set and SecLang, so policies can migrate between SecLang-compatible engines. Track upstream security advisories and keep deployment manifests and exceptions portable.