WAF rules explained: what they match and what they miss

A rule 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.

A network firewall rule matches addresses, ports and protocols: allow this port from this range, deny everything else. A WAF rule matches the request: a pattern in a parameter, a header that should not be there, a body that looks like a query. How a WAF differs from other defences is set out under waf comparisons.

They answer different questions and fail differently. A firewall rule that is too strict closes a service; a WAF rule that is too strict refuses individual customers while the service stays up, which is harder to notice.

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.

One engine that runs such shared sets is ModSecurity, and knowing how the engine and the rule set divide the work helps when reading a vendor description.

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.

Many rule engines take the alternative: they treat matches as contributions to a total and act only when enough of them accumulate on the same request. That converts a binary question into a threshold an operator can move, which is what makes a shared rule set usable on a real site without rewriting it, and in those engines the threshold is where most of the tuning happens. Bridge WAF exposes no such threshold: its configuration is the three modes, and tuning it means adding an exception.

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 practical side, turning filtering on without refusing real customers, is the subject of waf operations.

Three pieces of reference material sit behind most rule sets, and each has a page of its own here: the OWASP Top 10, the widely used community list of application security risks, with the positions on it a filtering layer can genuinely address; the OWASP Core Rule Set, the maintained rule set built around those risks, with its own scoring and severity settings; and the OWASP API Security Top 10, the equivalent list for interfaces used by other software, which fails differently and is also covered on API abuse. This page covers what any rule set built from them can see, and what it cannot.