Web Application Firewalls: Configuration Patterns That Don't Break Production

A Web Application Firewall sits between users and your application, inspecting traffic and blocking what looks malicious. The default rules catch common attacks — SQL injection, XSS, known bot patterns. The same default rules also block legitimate traffic in production with annoying regularity.

A WAF is one of those tools where the configuration is more important than the product. This post is the patterns for configuring a WAF that catches threats without producing constant false positives.

What a WAF Actually Does

A WAF inspects HTTP requests against a ruleset. Each rule decides allow, block, or log. Common rule categories:

• OWASP Top 10 patterns. SQL injection, XSS, command injection, path traversal.
• Bot detection. User-agent fingerprinting, behavioral analysis.
• Rate limiting. Too many requests from one IP or user.
• Geographic. Block traffic from specific countries.
• Custom rules. Application-specific patterns the team defines.

The output is "this request matched this rule, take this action."

The Free vs Paid Reality

Most clouds offer a WAF service:

• AWS WAF: Pay per request and rule evaluation. Cheap for low-traffic, scales with usage.
• Cloudflare WAF: Included in paid Cloudflare plans. Free tier has basic protection.
• Azure WAF: Integrated with Application Gateway or Front Door.
• GCP Cloud Armor: Managed WAF, pay per rule and request.

For most teams: the cloud-native WAF or Cloudflare. They are easy to set up and integrate with the rest of your infrastructure. Specialized appliances (F5, Imperva) are for enterprises with specific needs.

Managed Rule Sets

The fastest way to get a WAF running is the cloud provider's managed rule set:

• AWS WAF has the Core Rule Set (OWASP-based), plus bot control, IP reputation, and more.
• Cloudflare has the Managed Rules (Cloudflare Managed Ruleset).
• Azure WAF has the OWASP CRS.

Managed rules are updated by the provider as new threats emerge. They are usually correct on common attacks. They are also usually wrong on edge cases for your specific application.

The starting point: enable the managed ruleset in detection-only mode. Observe what it would have blocked. Then move to enforcement.

Detection-Only First, Always

The most common WAF mistake is enabling enforcement on day one. The result: legitimate traffic gets blocked, customers complain, the team rolls back, the WAF is now seen as "not worth the trouble."

The right rollout:

1. Enable the WAF in detection-only mode for at least two weeks.
2. Review the logs of blocked-or-would-be-blocked requests.
3. Tune the rules — disable ones with high false positive rates, adjust thresholds.
4. Enable enforcement on the rules you trust.
5. Leave the noisy ones in detection mode until they are tuned.

This takes weeks, not hours. The work is the tuning.

Common False Positives

Some patterns that look like attacks but are not:

SQL-shaped strings in legitimate fields. A user named "Robert'); DROP TABLE Students;--" is rare but legitimate. A user writing about a SQL injection vulnerability in a support ticket is more common.

Long base64 strings. Encoded data in legitimate APIs (especially for file uploads or signed URLs) can match many WAF rules.

Specific user agents. Some legitimate API clients use unusual user agents that trip bot detection.

Internal tools. Admin tools, integrations, scripts that hit the WAF with patterns the rules consider suspicious.

Geographic filtering. Blocking a country blocks legitimate users in that country, including diaspora.

For each false positive: either tune the rule (adjust thresholds, scope it to certain paths) or exempt specific paths or IPs.

Custom Rules

The managed rules cover the common attacks. Application-specific protection needs custom rules.

Examples:

# AWS WAF rule example - block requests to /admin from non-corporate IPs
{
  "Name": "AdminPathRestriction",
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "FieldToMatch": { "UriPath": {} },
            "PositionalConstraint": "STARTS_WITH",
            "SearchString": "/admin"
          }
        },
        {
          "NotStatement": {
            "Statement": {
              "IPSetReferenceStatement": {
                "ARN": "arn:aws:wafv2:::ipset/corp-ips"
              }
            }
          }
        }
      ]
    }
  },
  "Action": { "Block": {} }
}

Custom rules express things the managed ruleset cannot know: which paths are admin-only, which fields should never contain certain content, which clients are expected.

The most valuable custom rules tend to be:

• Path-based restrictions (admin endpoints, API key paths)
• Rate limits per logical action (login attempts, signup endpoints)
• Authentication bypasses for specific automated tools
• Custom blocking of known abusers (specific IPs, ASNs)

Rate Limiting

WAFs are good at rate limiting. The patterns:

# Limit login attempts to 5 per 5 minutes per IP
{
  "Name": "LoginRateLimit",
  "Statement": {
    "RateBasedStatement": {
      "Limit": 5,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "FieldToMatch": { "UriPath": {} },
          "PositionalConstraint": "EXACTLY",
          "SearchString": "/auth/login"
        }
      }
    }
  },
  "Action": { "Block": {} }
}

Rate limit by IP, by JA3 fingerprint, by user ID (if you can extract it). Different paths have different limits — login has stricter limits than browsing.

The WAF's rate limiting often catches credential stuffing before the application's. Both should exist; the WAF as a first line, the application as defense in depth.

Bot Management

Most public traffic includes bots. Some are legitimate (search engines, monitors). Many are malicious (scrapers, credential stuffers, scanners).

WAF bot management uses fingerprinting (TLS, HTTP/2 frame ordering, browser quirks) to distinguish real browsers from automated tools.

# Cloudflare bot fight mode - in dashboard, not config
# AWS WAF bot control - managed rule group

Bot management is one of the harder parts to tune. False positives include:

• Mobile apps with non-browser user agents
• API clients that look like bots
• Headless browser-based monitoring (Pingdom, etc.)

Exempt your own monitoring. Carefully test with your real users — especially mobile users.

Logging and Alerting

A WAF that just blocks without telling you what is happening is half a tool. Configure logging:

• All blocked requests go to a log (CloudWatch, GCP Logging, Cloudflare Logs).
• Pivot logs by rule to see what is being blocked at what rate.
• Alert on unusual spikes (blocked requests up 10x from baseline).

The logs are also the input for tuning. Every false positive ticket starts with "show me the WAF logs around the timestamp."

Integration with Application Layer

The WAF is one layer. The application has its own input validation, authentication, rate limiting. These layers should overlap.

The WAF catches:

• Generic attack patterns
• High-volume IP-based abuse
• Known-bad clients

The application catches:

• Authentication-aware logic
• Business-rule violations
• Anything that requires application context

Both are needed. A WAF without application security is a thin shell. Application security without a WAF is exposed to the broad-spectrum noise of the internet.

When the WAF Is Not Worth It

Some workloads do not benefit from a WAF:

• Internal-only APIs not exposed to the internet
• Static sites without user input
• APIs already heavily protected by application-level controls

A WAF is most valuable for public-facing applications with user input. Internal services and static sites get less benefit relative to the cost and tuning effort.

The Practical Path

For a new WAF deployment:

1. Pick the cloud-native WAF. AWS WAF if on AWS, Cloudflare if behind Cloudflare.
2. Enable managed rules in detection-only mode.
3. Run for 2-4 weeks. Collect logs.
4. Tune. Disable noisy rules, adjust thresholds, exempt false positives.
5. Move to enforcement, rule by rule.
6. Add custom rules for path restrictions and rate limits.
7. Wire up alerting for unusual block rates.

The total work is a month for the initial setup. Ongoing tuning is hours per month as new patterns emerge.

What This Buys

A well-tuned WAF blocks a meaningful percentage of automated probes and exploit attempts. It does not prevent targeted attacks against your specific application — that is the job of application security. It does reduce noise, raise the bar for unsophisticated attackers, and provide visibility into the attack patterns your application sees.

The investment is real. The benefit is real. The combination of "enabled without thought" and "disabled in frustration" is the worst outcome; either commit to tuning or do not deploy it.

Setting up or tuning a WAF for a production application and not sure how to balance protection with usability? We help teams configure WAFs that catch real threats without blocking legitimate traffic. scopeforged.com