Lab 9

WAF exception and false positive workflow

Lab 9 demonstrates how to respond when a security rule blocks legitimate traffic by narrowing the rule instead of disabling protection entirely.

Scenario

A security rule blocks a legitimate request. The customer wants to keep protection in place, but they do not want the WAF to break normal application functionality.

Objective

Create an intentional WAF block, validate that it stops traffic, then refine the rule so legitimate requests are allowed while suspicious requests are still blocked. The goal is to demonstrate a practical false positive workflow: observe, narrow, validate, and preserve protection.

Outcomes

  • Created an intentional WAF rule that initially blocked requests containing /upload.
  • Validated that the broad rule blocked the test upload path.
  • Refined the rule so it only blocks suspicious upload traffic.
  • Allowed legitimate requests to /upload.
  • Blocked requests to /upload when the query string contains attack=true.
  • Demonstrated how to resolve a false positive without turning off the WAF entirely.
  • Validated the final behavior using curl.

Environment / Build

  • Zone: ybarra-cflab.com
  • Protected hostname: www.ybarra-cflab.com
  • Original protected path: /upload
  • Cloudflare product area: Security → WAF → Custom rules
  • Initial broad expression: (http.request.uri.path contains "/upload")
  • Initial action: Block
  • Final narrowed expression: (http.request.uri.path contains "/upload" and http.request.uri.query contains "attack=true")
  • Final action: Block

Demonstrable Content

Initial broad block test:

curl -I https://www.ybarra-cflab.com/upload

Final legitimate traffic test:

curl -I https://www.ybarra-cflab.com/upload

Final suspicious traffic test:

curl -I "https://www.ybarra-cflab.com/upload?attack=true"

Expected final behavior:

  • /upload is allowed.
  • /upload?attack=true is blocked.
  • The WAF remains enabled and targeted.
  • Legitimate application behavior is restored without removing protection.

What Was Completed

  • Created a WAF custom rule to intentionally block upload-path traffic.
  • Validated the broad block behavior using curl.
  • Identified that the broad rule would also block legitimate upload requests.
  • Modified the expression to include the suspicious query string condition.
  • Validated that normal /upload requests were no longer blocked.
  • Validated that /upload?attack=true remained blocked.
  • Preserved protection while reducing the false positive impact.

Lab 9 Technical Summary

Lab 9 implemented a WAF false positive workflow using Cloudflare Custom Rules. The initial rule matched any request where the URI path contained /upload and blocked the request. That proved enforcement, but it was too broad because legitimate upload traffic could also be blocked. The rule was then narrowed to match only requests where the path contains /upload and the query string contains attack=true. This final expression allows normal upload requests while still blocking the suspicious test pattern. The lab demonstrates how to tune security controls by inspecting request attributes, narrowing rule logic, and validating both allowed and blocked cases.

Lab 9 Customer-Facing Summary

We simulated a common security issue: a WAF rule was protecting the application, but it was also blocking legitimate traffic. Instead of disabling the WAF, we narrowed the rule so normal upload traffic works while suspicious upload requests are still blocked. This gives the customer a safer outcome: protection remains active, the application works as expected, and the rule is more precise.