WAF rules explained: what they match and what they miss

It examines a request and decides whether some part of it matches a description. The description might concern the address requested, the headers, the parameters, the body, or a combination.

What matters is that the decision is made on the request alone. A rule knows nothing about who is asking, what they asked for previously, whether they are signed in, or what your application does with the value once it arrives. It sees text and compares it against a description of text that somebody believed indicates trouble.

This is why rules pair naturally with rate limiting: one judges the content of a single request, the other judges the volume across many, and neither can do the other's work.

Almost nobody writes a rule set from nothing, and understanding what you are inheriting matters more than the rules themselves.

Public rule sets are maintained by security communities and describe patterns associated with well-known classes of attack. They exist because those classes recur across every application, so the same descriptions are useful to everybody, and because keeping them current is more work than any one team should repeat.

The trade is visible from the start. A shared rule set knows nothing about your application, so it is written for the general case and errs toward catching things. What is normal traffic for your site may be exactly what somebody else's rule was written to stop, and neither party is wrong.

Treating every match as proof produces a system nobody can run, so mature rule sets do something more careful.

A single suspicious pattern is weak evidence. Text that resembles an injection attempt appears legitimately in search boxes, in support tickets, in code samples, and in any field where people write about software. Acting on one match would refuse all of that, constantly.

The alternative is to treat matches as contributions to a total, and to act only when enough of them accumulate on the same request. That converts a binary question into a threshold you can move, which is what makes a shared rule set usable on a real site without rewriting it. It also means the threshold, rather than the rules, is where most of your tuning happens.

Both are inevitable and they are not equally expensive, which decides how to set everything above.

It refuses something legitimate. A customer, a partner integration, or your own automation is stopped by a rule written about somebody else's threat. This failure is silent from your side: the person does not report it, they leave, and the log entry looks like a successful defence.

It misses something. An attack passes because nobody described that pattern, or because it was spread thin enough to stay below the threshold. This failure is visible eventually and can be responded to.

The asymmetry is the whole argument for caution. One failure mode you find out about and one you do not, which means an unwatched rule set drifts toward confident, invisible harm.

Three categories, and no threshold setting brings them into range.

Authorisation. Whether this person may see this record is a question about your data and your permissions. The request asking for it is entirely well formed, and nothing in it distinguishes the legitimate reader from somebody who changed a number in the address.

Business logic. Ordering at a price that should not exist, or using a workflow in an order nobody anticipated, produces requests that are valid individually and wrong in sequence. A rule sees one request.

Design decisions. A missing check, an operation that can be replayed, a secret in a place it should not be. These are properties of the application, and a filtering layer in front of it cannot supply what was never built.

Knowing this is not an argument against rules. It is what stops a rule set being treated as a substitute for the work it cannot do.

The same discipline the whole layer rests on, and it matters most here because rule matches are the hardest to predict.

Run a shared rule set in observation first, against your own real traffic, for long enough to include the unusual days. What you are looking for is not attacks; it is the requests your own site generates that happen to resemble somebody else's threat. Every one of those is a customer you would have refused, and you can only find them before enforcement, never after.

The pages below work through the reference material a rule set is built from: the widely used community list of application security risks and the positions on it a filtering layer can genuinely address, the maintained rule set built around those risks and how its scoring and severity settings behave in practice, and the equivalent list for interfaces used by other software rather than by people, which fails differently and is covered on API abuse.