Tuning a Cloud WAF Without Blocking Real Traffic

Vendor-managed rulesets, the OWASP-style sets most cloud WAFs ship with, catch the broad, well-known patterns: SQL injection strings, path traversal attempts, common exploit payloads. That coverage is worth having on by default, but it's generic by design, written to apply across every application the vendor's customers run, not yours specifically.

Treat it as the floor you build on, not the ceiling. The custom rules you add on top of it are what actually reflect the paths, parameters, and payload shapes your application receives, and that's the part a generic ruleset can't do for you.

Start from your own API surface: which paths exist, what type each parameter should be, what a legitimate payload looks like for the endpoints that matter most. Rules built from that shape catch things a generic signature misses and are far less likely to flag something legitimate as malicious.

This is also where attack surface scanning earns its keep. Attack surface scanning like Tenable's can tell you which endpoints are actually exposed to the internet, which is the starting point for deciding where WAF rules matter most, since it's common for a team to be surprised by an endpoint they forgot was public.

Every new custom rule should run in count or log-only mode first, recording what it would have matched without actually rejecting anything. Review a representative window of that log before flipping the rule to block, a few days at minimum, long enough to cover your actual traffic patterns rather than a quiet afternoon.

Skipping this step is how a well-intentioned rule turns into a support ticket queue, a legitimate field containing something that happens to look like a SQL keyword, a normal user agent that matches a pattern meant for a bot. Log-only mode catches that before a real user does.

A safe path for each new custom rule looks like this:

1. Write the rule from your own API surface: the paths that exist, the expected type of each parameter, and what a legitimate payload looks like.
2. Deploy it in count or log-only mode so it records what it would have matched without rejecting any traffic.
3. Review a representative window of that log, a few days at minimum, long enough to cover your real traffic patterns rather than a quiet afternoon.
4. Look for legitimate requests the rule would have blocked, and adjust the rule until those no longer match.
5. Switch the rule to block only once the log looks clean, and keep watching for false positives after the change.

Credential stuffing and scraping don't look malicious in a single request, they look wrong in volume: the same endpoint hit far more often than a real user would, from a spread of IPs that doesn't match normal traffic. No signature rule catches that pattern, because no single request in it looks different from a legitimate one.

Pair your signature-based rules with rate-based rules scoped to the endpoints most worth protecting, login, password reset, checkout, and tune the threshold against your actual traffic rather than an arbitrary round number. Too low and you'll block real bursts of legitimate use; too high and the rule never fires.

Say a login endpoint normally sees a handful of attempts per IP in an hour from real users retrying a mistyped password. A rate rule set well above that baseline still catches a credential-stuffing run trying hundreds of password guesses against different accounts from the same source, without ever touching a legitimate user's retry.

A WAF is a perimeter layer, not a substitute for input validation, authorization checks, or actually patching a known vulnerability in your application. A WAF rule can shield a known issue while you work through your own patch timeline, but it isn't a fix, and federal patch guidance treats a known, exploited vulnerability as something to remediate in days, not quarters¹.

Endpoint-level protection is a related but different layer worth reviewing separately, see a comparison of major endpoint platforms if you haven't settled on one. A WAF stops what reaches your application over HTTP; it does nothing for what happens on the machines running it.