How to Read a WAF Block Log

A WAF block log is not a list of attacks. It is a list of requests that matched a block rule -- which may include real attacks, misconfigured clients, legitimate users who exceeded rate limits, and your own monitoring systems. Reading a WAF block log correctly requires distinguishing these categories before drawing any conclusions about your attack surface or your false positive rate.

The most common error in WAF log interpretation is treating all block events as attacks. This produces overconfidence ("we blocked 50,000 attacks this month") and leads to under-investigation of actual incidents that are buried in the noise. The second most common error is treating all block events as false positives and disabling rules to restore access. A WAF that blocks nothing is not a correctly configured WAF.

Anatomy of a WAF Block Event

A Cloudflare WAF block event log entry contains: timestamp, source IP, user agent, request path and method, matched rule ID and rule description, action taken (block/challenge/log), and the response code returned. The rule ID is the most important field for analysis -- it identifies which specific rule matched, which tells you whether the block was from a rate limit rule (request volume) or a signature rule (request content).

# Cloudflare Firewall Events JSON (simplified):
{
  "timestamp": "2026-06-05T14:32:11Z",
  "clientIP": "203.0.113.47",
  "userAgent": "Mozilla/5.0 (compatible; AhrefsBot/7.0)",
  "requestMethod": "GET",
  "requestPath": "/api/v1/products",
  "ruleId": "ddos-rate-limit-products",
  "ruleDescription": "Rate limit: /api/v1/products 50 req/min per IP",
  "action": "block",
  "responseCode": 429,
  "edgeLocation": "ORD"
}
# This is a bot crawler (Ahrefs) hitting a rate limit -- expected, not malicious

Classifying Block Events

After pulling a block event sample, group events by rule ID and by client user agent. The groupings reveal the source category: events from known crawler user agents (Googlebot, AhrefsBot, SemrushBot) are legitimate automated traffic that exceeded a rate limit, not attacks. Events from data center IP ranges with tool user agents (curl, python-requests, Go-http-client) are likely automated clients that may be legitimate API consumers or attack tools -- look at the request path and frequency to distinguish. Events where the user agent is a browser string but the IP is a data center ASN are likely bots spoofing browser user agents -- suspicious but not conclusive.

Identifying False Positives

A false positive in a rate limit rule is a legitimate client that exceeded the threshold. The indicators: a known client IP (your own monitoring, a partner's integration), a consistent request pattern that matches a legitimate use case (polling at a predictable interval), and a request path and method that the client is known to access. False positives from rate limits are resolved by adding the client IP to an exception list or by adjusting the threshold upward if the current limit is consistently tripped by legitimate traffic.

Identifying Real Attacks in Log Data

Real attack traffic has distinctive patterns in WAF logs: high block volume from a large number of distinct IPs within a short time window (distributed attack), blocks concentrated on a single expensive endpoint, requests with identical user agents across many IPs (botnet with uniform configuration), and rapid onset (thousands of blocks appearing within seconds). Rate limit block events during a distributed attack look different from normal false-positive patterns: the volume is high, the source IPs are diverse (many different /24 subnets or different ASNs), and the targeted path is consistent.