A Web Application Firewall that has never been tuned is a liability dressed up as a security tool. In detection mode, it generates noise. In blocking mode with default rules, it blocks legitimate users, breaks application functionality, and creates support tickets that distract from actual security work. I have seen teams disable WAFs entirely because the false positive rate made them unusable, which is worse than never having one.
A properly configured WAF blocks real attacks, generates actionable alerts, and is invisible to legitimate users. Getting there requires understanding what WAFs actually do, how to tune rule sets, and how to build the feedback loop that keeps rules calibrated over time.
What a WAF Does
A WAF inspects HTTP/HTTPS request and response content and applies rules to block, allow, or log traffic based on what it finds. It operates at Layer 7 (the application layer) of the network stack, which means it can read request bodies, headers, query parameters, and cookies.
This is distinct from a network firewall (Layer 3/4), which operates on IP addresses and ports. A network firewall cannot distinguish a valid login request from a SQL injection attack because both arrive on port 443 with valid TLS. A WAF can.
Common attack patterns that WAFs detect and block:
- SQL injection: Payloads like
' OR '1'='1in form fields, query parameters, or headers attempting to manipulate database queries - Cross-site scripting (XSS):
<script>alert(1)</script>in user-submitted content (see our frontend web security guide for input sanitization) - Path traversal:
../../../../etc/passwdin URL paths - Remote code execution: Server-side template injection, deserialization attacks
- HTTP protocol violations: Malformed requests that exploit parser inconsistencies
WAFs do not replace secure application code. They are a defense-in-depth layer that catches exploitation attempts against known vulnerability classes. An application with a SQL injection vulnerability is still vulnerable; the WAF makes that vulnerability much harder to exploit. Our small business cybersecurity checklist covers how WAF rules fit alongside code-level defenses in a layered security stack.
How WAF Rules Work
Most WAFs evaluate requests against a ruleset using pattern matching. The OWASP Core Rule Set (CRS) is the industry-standard ruleset, used as the default by ModSecurity, Cloudflare WAF, AWS WAF managed rules, and most commercial WAF products.
CRS rules assign anomaly scores to requests based on what they match. A request matching a single low-confidence rule might score 3. A request matching a high-confidence SQL injection pattern scores 15. The WAF blocks requests that exceed a configured threshold (commonly 10 for paranoia level 1, lower for stricter modes).
This scoring approach reduces false positives by requiring multiple indicators before blocking, while still catching obvious attacks early.
Rule Structure
WAF rules typically match on request properties: the URI path, query string parameters, request body (POST/PUT data), HTTP headers like User-Agent, Referer, and Cookie, and the HTTP method. Some WAFs can also inspect response properties, such as response bodies containing credit card numbers or error messages.
A CRS rule detecting SQL injection in query parameters uses ModSecurity’s SecRule directive with the @detectSQLi operator, configured to deny with a 403 status, tag the match as attack-sqli, and assign a CRITICAL severity.
WAF Deployment Options
Cloudflare WAF
Cloudflare WAF is available on all paid plans and requires routing traffic through Cloudflare’s network. This means Cloudflare is in the critical path for all your HTTP traffic, which provides DDoS mitigation and global CDN benefits alongside WAF protection. If you already route traffic through an edge network, our edge CDN comparison guide covers how edge proxying and WAF rules work together.
Cloudflare WAF strengths:
- Zero infrastructure to manage
- DDoS mitigation integrated
- Rules updated by Cloudflare’s threat intelligence
- Custom rules with a visual rule builder
Considerations:
- Cloudflare can see all decrypted traffic
- Rules and logging require Cloudflare plans
- Custom rules syntax differs from CRS
AWS WAF
AWS WAF integrates with CloudFront, Application Load Balancer, API Gateway, and AppSync. Pricing is per Web ACL, per rule, and per million requests processed.
AWS offers managed rule groups that mirror CRS functionality and update automatically. Custom rules use a JSON-based rule language where each rule has a name, a priority, a statement (such as a managed rule group reference), an action, and a visibility config controlling sampled requests and CloudWatch metrics.
ModSecurity / Coraza
ModSecurity is an open-source WAF engine that runs as an Nginx or Apache module. Coraza is a newer, actively maintained Go implementation compatible with CRS.
Running your own WAF engine gives you complete control over rules and no dependency on a cloud provider, but requires more operational work for updates, tuning, and log management. With Nginx, you load the ModSecurity module via load_module modules/ngx_http_modsecurity_module.so;, enable it per server block with modsecurity on;, and point modsecurity_rules_file at your main config, which includes the CRS setup file and the rule files. For teams running origin servers across multiple regions, our multi-region architecture guide covers the traffic-routing decisions that sit upstream of a self-managed WAF.
Detection Mode vs Blocking Mode
Always start in detection mode. Detection mode logs what would be blocked without actually blocking it. This reveals the false positive rate before any user is affected.
Detection mode in ModSecurity is set with SecRuleEngine DetectionOnly, while blocking mode uses SecRuleEngine On. In Cloudflare, this is “Log” mode versus “Block” mode per rule or WAF action.
The detection mode process:
- Enable detection mode with CRS rules at paranoia level 1.
- Run in detection mode for 1-2 weeks across all traffic, including your application’s automated tests.
- Review all blocked events. Classify each as a true positive (actual attack) or false positive (legitimate traffic incorrectly matched).
- For each false positive, create an exception rule.
- Repeat until the false positive rate is acceptable.
- Switch to blocking mode.
This process takes time. Teams that skip it and switch directly to blocking mode find their application partially broken and spend days debugging which WAF rule is causing the problem.
Managing False Positives
False positives are the primary operational challenge of running a WAF. Legitimate requests that trigger attack signatures are unavoidable with broad rule sets.
Common sources of false positives:
Rich text editors. HTML content posted from WYSIWYG editors contains tags, attributes, and JavaScript event handlers that look like XSS. Rule exceptions for the specific endpoints accepting HTML input are necessary.
API payloads with JSON. JSON bodies sometimes contain strings that pattern-match SQL keywords (select, insert, drop, table) even in completely benign contexts.
URL parameters with special characters. Application-specific parameters that legitimately contain characters like ', ", or < trigger injection rules.
Search functionality. Natural language search queries can contain phrases that match attack patterns.
Writing Exception Rules
Exception rules whitelist specific combinations of URI, parameter, and match condition rather than disabling the rule entirely.
In CRS/ModSecurity:
# Allow HTML in the 'content' body parameter on the /api/posts endpoint
SecRule REQUEST_URI "@beginsWith /api/posts" \
"id:1001,\
phase:2,\
pass,\
nolog,\
ctl:ruleRemoveTargetById=941100;ARGS:content"This removes the XSS rule (941100) from being evaluated against the content body parameter on POST requests to /api/posts, while keeping that rule active for all other parameters and all other endpoints.
In Cloudflare, the equivalent is a custom rule expression like (http.request.uri.path eq "/api/posts" and http.request.method eq "POST"). to “Skip” with “Skip all remaining custom rules” and “Bypass” for OWASP managed rules.
Exceptions should be as narrow as possible. “Disable SQL injection rules for this endpoint” is far safer than “disable SQL injection rules sitewide.” The goal is handling the legitimate use case while keeping protection active everywhere else.
Custom Rate Limiting Rules
Rate limiting is often a WAF capability and is one of the highest-value rules to configure. It stops credential stuffing attacks, API abuse, and brute force attempts. In AWS WAF, a rate-based rule sets a request limit per IP and can be scoped down to a specific path; a rule limiting /auth/login to 100 requests per 5-minute window per IP blocks any address that exceeds that threshold. This blocks any IP that makes more than 100 requests to /auth/login within a 5-minute window. Rate limiting works best as one layer in a broader abuse-defense setup; pairing these rules with two-factor authentication on the login itself blunts credential stuffing even when limits are bypassed.
WAF Logging and Alerting
A WAF without reviewed logs provides no operational value beyond the rules themselves. Configure:
Centralized logging. WAF logs should flow to your SIEM or log aggregation system (Splunk, Datadog, Elastic Stack) alongside application logs. Correlation between WAF block events and application errors reveals whether the WAF is causing application problems.
Alerting on attack patterns. Alert when a single IP generates more than 50 blocked requests in 5 minutes. Alert when a new rule starts blocking at a high rate (possible new false positive). Alert when the total block rate spikes significantly above baseline.
Weekly review process. Review the top 10 blocked request patterns weekly. New false positives reveal themselves as a consistent pattern of blocks against known good endpoints. True positives reveal attack patterns being actively exploited.
The Maintenance Reality
A WAF requires ongoing maintenance. Your application changes, and rule exceptions that were accurate six months ago may be too broad or missing after new endpoints are added. Attack techniques evolve, and CRS rules need periodic updates.
Update CRS rules on a quarterly schedule at minimum. Run the update in detection mode first to catch any new false positives introduced by new rules before switching to blocking.
The teams that get the most value from WAFs treat them as active security infrastructure, not a set-and-forget appliance. The initial tuning investment is significant. The ongoing maintenance is modest if you run a structured review process rather than reacting to incidents.
What Most Guides Get Wrong
Most WAF guides treat the default rule set as a finished product and frame tuning as an optional refinement. In practice, the default rules are a starting point calibrated for generic applications, and every real application violates some assumption baked into them. Guides also overstate the value of paranoia levels, presenting higher levels as “better security” without mentioning that paranoia level 3 on a business application with form submissions and rich text will produce thousands of false positives a day. Another common mistake is recommending IP-based rate limiting as the answer to credential stuffing, when residential proxy networks and botnets rotate IPs cheaply and make per-IP limits a speed bump rather than a wall. Most guides skip the hardest operational question entirely: who reviews the logs, how often, and what threshold justifies an exception rule, which is the actual work of running a WAF. The detection-mode period is usually described as a one-time step, but the useful pattern is running detection mode again after every CRS update and every application release, since both introduce new signatures and new payloads. Finally, guides rarely admit that a WAF mostly buys time. It raises the cost of exploiting a vulnerability; it does not remove the vulnerability, and treating blocked request counts as a security score encourages teams to ignore the underlying code problems the blocks are pointing at.
Conclusion
Start with a managed WAF on detection mode and accept that the first two weeks are calibration, not protection. Work through every false positive with narrow exception rules that target a specific parameter on a specific endpoint, never a sitewide rule disable. Add rate limiting on your login and other abuse-prone endpoints, and review blocked traffic weekly on a fixed schedule instead of waiting for incident reports. Re-run detection mode after every ruleset update and every significant application change. Do that consistently, and the WAF becomes quiet infrastructure that blocks real attacks without your users ever knowing it exists.
