A WAF protects web applications by filtering and monitoring HTTP traffic. It blocks attacks like SQL injection and XSS that network firewalls cannot see. Here is everything you need to know.
A Web Application Firewall (WAF) monitors HTTP/HTTPS traffic between users and your web application. It inspects request URLs, headers, query parameters, POST bodies, and cookies for patterns that indicate an attack. When it detects a malicious request, it blocks the attacker.
# What a network firewall sees (iptables/firewalld)
IP: 91.108.4.30 → Port 443 → ALLOW (port is open)
# What a WAF sees inside that allowed connection
IP: 91.108.4.30 → GET /search?q=1' OR 1=1-- → BLOCK (SQL injection)
IP: 91.108.4.30 → GET /../../etc/passwd → BLOCK (path traversal)
IP: 91.108.4.30 → POST /login (10,000 attempts) → BLOCK (brute force)
Key difference from network firewalls: A traditional firewall (iptables, firewalld, UFW, AWS Security Groups) filters traffic by IP address, port, and protocol. It cannot see what is inside an HTTP request. A WAF operates at the application layer (Layer 7) and understands HTTP semantics. It knows that 1' OR 1=1-- in a search query is an SQL injection attempt, not a legitimate search. For web server hardening that complements WAF protection, see our nginx security guide.
A WAF protects against the OWASP Top 10, the industry-standard list of the most critical web application security risks. Here are the attacks a WAF detects.
Attackers inject SQL code into query parameters to read, modify, or delete database contents. Example: adding ' OR 1=1-- to a login form to bypass authentication.
Malicious JavaScript is injected into web pages viewed by other users. Can steal session cookies, redirect users, or modify page content. Stored XSS persists in the database.
Attackers use ../ sequences to escape the web root and read system files like /etc/passwd or /etc/shadow. Also called directory traversal or dot-dot-slash attacks.
The most critical attack type. Attackers execute arbitrary commands on your server through vulnerable web applications. Often exploits deserialization flaws or command injection.
Forces the server to make HTTP requests to internal services (metadata endpoints, databases, admin panels) that are not directly accessible from the internet.
Brute force attacks on login pages, credential stuffing with leaked password databases, and session fixation. WAFs can rate-limit login endpoints and detect stuffing patterns.
Exploits XML parsers to read local files, perform SSRF, or cause denial of service. Targets applications that accept XML input (SOAP APIs, document uploads).
Exploits differences between how front-end and back-end servers parse HTTP requests. Can bypass WAFs, poison caches, and hijack other users' requests.
There are three main approaches to web application firewalling. Each has different trade-offs in terms of deployment, cost, and how they handle traffic.
A cloud WAF sits between the internet and your server, acting as a reverse proxy. All traffic passes through the cloud provider's infrastructure before reaching your server. Examples include Cloudflare WAF, AWS WAF, Sucuri, and Akamai.
A host-based WAF runs directly on your web server as a module. It inspects every HTTP request inline before your application processes it. The most common example is ModSecurity, available for Apache, nginx, and IIS, typically paired with the OWASP Core Rule Set (CRS).
A log-based WAF reads your web server's access logs after the request is processed, detects attack patterns, and blocks the attacker's IP at the firewall level. This is how Defensia works. The web server handles requests normally; the WAF agent runs as a separate process.
If you run any web application accessible from the internet, yes. Here is why.
A network firewall (iptables, UFW, Security Groups) only blocks ports. It cannot detect SQL injection on an open port 443. A WAF fills that gap. Think of it as the difference between a locked door (firewall) and a security guard who checks what people carry through the door (WAF).
Defensia uses a log-based WAF architecture. A lightweight Go agent runs on your server, reads nginx and Apache access logs in real time, and blocks attackers via iptables.
# How it works
nginx/access.log or Apache/access.log
| Auto-detected. No config files.
v
WAF watcher goroutine
| Pattern matching: 15+ OWASP attack types
| SQL injection, XSS, path traversal, RCE, SSRF...
v
IP scoring engine
| Each attack adds points to the IP's score
| Score >= 80 -> ban 1 hour
| Score >= 100 -> blacklist 24 hours
v
ipset add defensia-bans <IP>
| Firewall blocks all traffic from this IP
| Not just HTTP — SSH, SMTP, everything
v
Dashboard + alerts
Real-time event feed, charts, Slack/email notifications
The key advantage: Defensia requires zero changes to your web server configuration. No modules to compile, no rules to tune, no proxy to manage. Install the agent with one command and your access logs become an active defense layer. Full WAF documentation →
How the three WAF types compare side by side.
| Feature | Cloud WAF | ModSecurity | Defensia |
|---|---|---|---|
| Deployment | DNS change | Compile module | curl | bash |
| Configuration | Web dashboard | 200+ rule files | Zero config |
| Performance impact | Adds latency (proxy) | Adds latency (inline) | Zero (async) |
| Blocks first request | Yes | Yes | No (blocks IP after first) |
| Server changes | None | Module + rules | None |
| DDoS protection | Yes | No | No (use Cloudflare) |
| SSH protection | No | No | Yes (15 patterns) |
| Malware scanning | No | No | Yes (64K+ signatures) |
| Dashboard | Yes | No | Yes (real-time) |
| Typical cost | $20-200+/mo | Free | Free / EUR 9/mo |
A network firewall (iptables, UFW, firewalld) filters traffic by IP address, port, and protocol. It operates at layers 3-4 (network and transport). A WAF operates at layer 7 (application) and inspects the contents of HTTP requests. A firewall allows or blocks a connection; a WAF allows or blocks specific requests within an allowed connection. You need both: the firewall to close unused ports, the WAF to protect open ones.
Cloudflare includes a WAF as part of its reverse proxy service. It inspects HTTP traffic at their edge servers before forwarding requests to your origin. However, Cloudflare only protects HTTP/HTTPS traffic that passes through their proxy. It cannot protect SSH, email, databases, or other services on your server. If your origin IP is exposed, Cloudflare can be bypassed entirely.
Yes. HTTPS (TLS) encrypts the connection between the browser and your server, preventing eavesdropping. It does not inspect or filter the content of requests. An attacker can send SQL injection, XSS, or path traversal attacks over a perfectly valid HTTPS connection. HTTPS protects data in transit; a WAF protects your application from malicious input.
Cloud WAFs range from $20/month (Cloudflare Pro) to $200+/month (AWS WAF, Akamai) depending on traffic volume and features. ModSecurity is free but requires significant time to configure and maintain. Defensia is free for 1 server with SSH protection and dashboard; the WAF is included in Pro at EUR 9/server/month.
No. A WAF blocks known attack patterns. It is one layer of defense, not a complete security solution. You still need to patch your software, use strong authentication, restrict permissions, and monitor for anomalies. A WAF significantly reduces your attack surface but cannot replace secure coding practices or system hardening.
15+ OWASP attack types from access logs.
Hardening guide with config examples.
Hardening guide for Apache HTTP Server.
Complete server protection guide.
15 detection patterns, ipset blocking.
Full comparison: fail2ban vs Defensia.
No modules to compile. No rules to configure. No proxy to manage. Just install and protect.
No credit card required. Free for one server.