WAF Configuration Guide: How to Protect a Website Without Blocking Users

Configure a WAF in stages: map the application, enable a maintained baseline, observe matches, test representative requests, add narrow exceptions, and enforce only after false positives are understood. Avoid starting with a giant blocklist or switching every rule to block on day one. A WAF should reduce exploit traffic while preserving legitimate browsers, APIs, crawlers, partners, and internal workflows.

A WAF operates at the HTTP application layer. It can inspect methods, paths, headers, query strings, cookies, and request bodies for signals associated with attacks such as SQL injection, cross-site scripting, path traversal, command injection, and known vulnerable components. It does not replace secure code, patching, authentication, authorization, secrets management, rate limiting, or DDoS protection.

Start with an application map

List public hostnames, API versions, methods, content types, authentication flows, upload endpoints, webhooks, admin paths, partner integrations, and expected clients. Identify which routes accept JSON, XML, multipart forms, GraphQL, or rich text. Record normal response codes and traffic volumes by route. This inventory gives you a basis for both policy and testing.

Separate traffic by risk and business impact. Login, password reset, checkout, account changes, and administrative endpoints deserve tighter controls than public product pages. APIs may need schema validation and per-client rate limits in addition to WAF inspection. Search and upload endpoints often generate unusual but legitimate payloads and are common sources of false positives.

Put the WAF in front of the origin and confirm that the origin cannot be reached through an unprotected hostname or leaked address. Preserve the real client IP through the provider's trusted mechanism, and ensure application logs do not blindly trust a client-supplied forwarding header. Establish TLS, host-header, body-size, timeout, and upload limits deliberately.

Build a layered policy

1. Use a maintained managed ruleset. Select rules relevant to the technologies and frameworks you actually run. A maintained set evolves with new vulnerabilities; it is not a substitute for knowing your stack.

2. Add high-confidence custom rules. Block clearly malicious paths, impossible methods, known exploit probes, and requests that violate your public contract. Match on multiple signals where possible instead of blocking a single user-agent or country.

3. Apply a graduated action. Use log or alert for discovery, a managed or non-interactive challenge for suspicious browser traffic where appropriate, and block for high-confidence malicious requests. APIs and machine clients may not complete browser challenges, so use authentication, tokens, IP or network identity, and rate limits instead.

4. Scope rules. Apply an admin rule to the admin path, an API rule to the API host, and an upload rule to upload endpoints. Narrow scope reduces both processing noise and the blast radius of a mistake.

5. Create precise exceptions. Exclude a specific rule, parameter, path, or trusted integration only when the application's behavior requires it. Prefer an exception over turning off the entire managed ruleset. Keep a record of why the exception exists.

Cloudflare equivalents include the Cloudflare Managed Ruleset, custom WAF rules, managed challenge, log actions, ruleset overrides, and scoped exceptions. Cloudflare explicitly warns against enabling every available rule indiscriminately because disabled-by-default rules can affect legitimate traffic. Fastly equivalents include the Next-Gen WAF, request rules, signal exclusions, custom actions, sampled request logging, and its request simulator. The exact action names and evaluation order differ, so test the provider configuration rather than copying a policy verbatim.

Roll out without breaking users

Use a representative test set before enforcement. Include normal browser requests, mobile and desktop flows, localized URLs, API clients, signed webhooks, payment callbacks, uploads, search terms, encoded characters, large but valid bodies, and known security test cases in a non-production environment. Include requests from real partners if their traffic is contractually authorized for testing.

For Cloudflare, deploy managed rules and use log or a scoped non-blocking action while you review matches. For Fastly, use the Next-Gen WAF simulator and request rules to test logic before production; keep matched request logging appropriate to privacy requirements. In either platform, capture rule ID, action, hostname, path, method, client category, country, request ID, and response status. Do not log full credentials, tokens, payment data, or unredacted sensitive payloads.

Review false positives by business impact, not just count. A rule that matches one password-reset callback may be more important than a rule that matches thousands of harmless probes. Ask whether the request is actually required, whether the application can normalize its input, or whether the policy should be narrowed. Add an exception only after the first two questions are answered.

Promote changes in small batches. Announce the change, capture a configuration version, define an owner, watch customer journeys, and keep a rollback path. Re-test after managed ruleset updates because a provider can add or change detections over time.

Test and observe continuously

Measure blocked, challenged, logged, allowed, and origin-error requests by rule, route, client category, and deployment version. Track login success, checkout completion, API error rates, webhook delivery, latency, and support reports alongside security detections. A sudden drop in traffic is not proof of better security; it may indicate a broken integration.

Use synthetic checks for the most important journeys and canaries for policy changes. Test with safe attack strings in a controlled environment and never launch unapproved traffic at a third party. Review WAF logs with application logs so a blocked request can be distinguished from an origin rejection or a client-side failure.

Common mistakes are trusting user-agent strings as identity, allowing every office IP permanently, placing broad allow rules before inspection, ignoring IPv6, forgetting non-browser API clients, logging sensitive payloads, using challenges on webhooks, and leaving temporary exceptions forever. A managed WAF belongs alongside rate limiting and DDoS protection, not instead of them.

For implementation guidance, see the Cloudflare Managed Ruleset documentation and Fastly's WAF simulator reference. For a policy review that balances security and availability, contact Optimi.

There are only two hard things in Computer Science: cache invalidation and naming things.