What a WAF does — and why deployment is the easy part
A web application firewall inspects HTTP traffic and blocks attacks — SQL injection, XSS, CSRF, path traversal. Deploying one takes an hour. Tuning it so it stops attacks without blocking your checkout forms, your API calls, and your legitimate users takes expertise. This guide covers how WAFs work. If you want one managed for you, see Managed WAF.

How a WAF works
A WAF sits between your users and your application, inspecting every HTTP/HTTPS request. It applies rules to block known attack patterns — and this is where most self-managed deployments go wrong.
Request inspection at Layer 7
WAF operates at the application layer (L7) of the OSI model — inspecting HTTP headers, cookies, query strings, and request bodies for attack signatures. It does not inspect raw TCP/UDP traffic (that is L3/L4 DDoS protection).
Rule-based blocking
Rules define what looks malicious — SQL keywords in form fields, JavaScript in input parameters, directory traversal sequences in URLs. The OWASP Core Rule Set (CRS) is the industry standard baseline, covering the OWASP Top 10 attack classes.
False positives: the real challenge
Default CRS rules are intentionally strict. A WooCommerce order note with 'select your size' can trigger a SQL injection rule. A blog post about JavaScript can trigger an XSS rule. Tuning false positives per application is 80% of the work.
Attack types WAF blocks
SQL injection (SQLi), Cross-site scripting (XSS), Cross-site request forgery (CSRF), Path traversal (directory traversal), Command injection, Server-side request forgery (SSRF), Remote file inclusion (RFI).
What WAF does NOT block
Authentication bypass (broken auth logic in your code), business logic flaws, volumetric DDoS at the network layer (see /security/ddos/), malware in uploaded files (needs server-side scanning), zero-day exploits with no rule yet.
WAF deployment modes
Detection mode: log all rule matches without blocking — used during tuning. Prevention mode: actively block matching requests. Cloudflare WAF (CDN layer), ModSecurity/Coraza (server-side), AWS WAF (for EC2/ALB/CloudFront) are the three common deployment architectures.
WAF engine comparison
Three major WAF engines used in production. The right choice depends on your infrastructure and application stack.
| Feature | ModSecurity | Coraza | AWS WAF |
|---|---|---|---|
| Language | C | Go | Managed cloud |
| OWASP CRS support | Yes | Yes | Via managed rule groups |
| Best for | Apache/Nginx on dedicated | High-performance Nginx/Caddy | EC2/ALB/CloudFront |
| Performance overhead | Low–moderate | Very low | Minimal (cloud-native) |
| Custom rule complexity | High (SecRule syntax) | High (SecRule compatible) | Moderate (JSON rules) |
| Managed by ZenoCloud | Yes | Yes | Yes |
Language
OWASP CRS support
Best for
Performance overhead
Custom rule complexity
Managed by ZenoCloud
* ZenoCloud selects the appropriate WAF engine based on your server stack and application during onboarding. See /security/managed-waf/ for the managed service.
WAF questions
Do I need a WAF if I'm already using Cloudflare?
What is the OWASP Top 10 and does a WAF cover it?
How does WAF affect website performance?
Can a WAF protect against zero-day vulnerabilities?
Is WAF required for PCI DSS?
Where can I get ZenoCloud to manage my WAF?
Skip the tuning headache. We manage it.
WAF deployment takes an hour. Tuning it so it doesn't block your users takes weeks. Let our team handle it — 14-day detection phase, application-specific rules, monthly review.