Web Application Firewalls promise to protect your applications from OWASP Top 10 attacks and beyond. In reality, most WAF deployments either run in detection mode forever because the team is afraid to block traffic, or they block so much legitimate traffic that developers route around them.
The gap between promise and reality is rule quality. Good WAF rules detect actual attacks with minimal false positives. Bad rules generate noise that everyone ignores.
Why Default Rule Sets Fail
Every WAF ships with a default rule set. ModSecurity has the Core Rule Set (CRS). AWS WAF has managed rule groups. Cloudflare has its own managed rules. These are starting points, not finished configurations.
Default rules are written to be broadly applicable. They detect common attack patterns across any application. But your application is not any application. It has specific input patterns, specific URL structures, and specific legitimate use cases that may trigger generic rules.
A developer documentation site that allows HTML in user-submitted content will trigger every XSS rule in the default set. An API that accepts base64-encoded payloads will trigger SQL injection rules that match base64 strings. A file upload endpoint will trigger rules designed to detect webshell uploads.
The fix is not disabling rules wholesale. It is tuning rules to understand your application's legitimate behavior.
Rule Tuning Process
Phase 1: Detection Mode
Deploy your WAF in detection mode first. Log all events without blocking any traffic. Run in this mode for at least two weeks to capture a full range of legitimate traffic patterns.
During this phase, collect data on every triggered rule, the request details that triggered it, and whether the request was legitimate or malicious. This data drives your tuning decisions.
Phase 2: Analyze and Classify
Review every triggered rule and classify the events:
True positives: Actual attacks detected correctly. These rules work and should remain active.
False positives: Legitimate requests flagged as attacks. These rules need tuning.
True negatives: Normal traffic that was not flagged. No action needed.
False negatives: Attacks that were not detected. These indicate gaps in your rule set.
Focus on false positives first. They are the primary reason WAF deployments fail.
Phase 3: Tune Rules
For each false positive, decide the appropriate response:
Exclude the specific path: If a rule only produces false positives on one URL, exclude that URL from the rule rather than disabling the rule globally.
Adjust the rule sensitivity: Some rules have configurable thresholds. Increase the detection threshold to reduce false positives while maintaining detection of actual attacks.
Create an exception: If a specific parameter legitimately contains content that looks like an attack, create a rule exception for that parameter.
Disable the rule: Only as a last resort, and only if the protection is provided by another control.
Phase 4: Enable Blocking
After tuning, enable blocking mode for the tuned rules. Start with high-confidence rules that had zero false positives during the detection phase. Gradually enable blocking for lower-confidence rules as you build confidence in the tuning.
Writing Custom Rules
Default rule sets catch common attacks. Custom rules catch attacks specific to your application.
Protect Business Logic
WAFs can enforce business logic constraints that application code might miss. If your API requires a specific header for authentication, write a rule that blocks requests without that header at the WAF level. If certain URL paths should only accept specific HTTP methods, enforce that in WAF rules.
Virtual Patching
When a vulnerability is discovered in your application but a code fix takes time, a WAF rule can provide immediate protection. The rule blocks the specific attack pattern that exploits the vulnerability while development works on the permanent fix.
Virtual patches should be specific. A rule that blocks the exploit for CVE-2024-12345 should match the exact attack pattern, not broadly block traffic to the affected endpoint.
Geo-Blocking
If your application serves a specific geographic region, blocking traffic from regions you do not serve eliminates a significant volume of automated attacks. This is not a security control in itself, but it reduces the noise that your other rules need to handle.
Bot Detection
Write rules that identify and handle bot traffic. Look for missing or inconsistent User-Agent headers, unusual request patterns, and known bot signatures. Not all bots are malicious, but categorizing bot traffic separately improves your visibility into human traffic patterns.
Rule Organization
Use Rule Groups
Organize rules into logical groups: SQL injection rules, XSS rules, application-specific rules, and virtual patches. This makes it easier to enable, disable, and tune categories of rules independently.
Document Every Rule
Each custom rule should have documentation that explains what attack it detects, why it was created, what the expected false positive rate is, and when it should be reviewed or removed.
Version Control Your Rules
Store WAF rules in version control alongside your application code. Review rule changes with the same rigor as code changes. An incorrect WAF rule can cause an outage just as effectively as a code bug.
Monitoring and Metrics
Track Rule Hit Rates
Monitor which rules are triggered most frequently. A rule that fires thousands of times per day is either detecting a real and persistent attack or producing false positives. Investigate the high-hitters regularly.
Measure False Positive Rates
Continuously sample blocked requests to verify they are actual attacks. A blocking rule that is correct 99% of the time still blocks 1% of legitimate traffic, which might be thousands of requests per day.
Alert on Anomalies
Create alerts for sudden changes in WAF activity: a rule that normally fires 10 times per day suddenly firing 10,000 times, new rules triggering for the first time, or a significant increase in blocked traffic.
How Safeguard.sh Helps
Safeguard.sh complements WAF protection by addressing the supply chain vulnerabilities that WAF rules cannot detect. While your WAF inspects incoming traffic for attack patterns, Safeguard.sh inspects the application code and dependencies for known vulnerabilities that those attacks might target. Together, they provide layered defense: Safeguard.sh reduces the number of exploitable vulnerabilities, and the WAF blocks exploitation attempts against any that remain.