Cloud WAF: How to Evaluate One Without Trusting the Comparison Charts

A cloud web application firewall inspects HTTP requests before they reach your origin and blocks the ones matching known attack patterns, and whether it helps or hurts depends almost entirely on how you handle the requests it gets wrong.

Every vendor comparison ranks on detection rate, which is the easier half of the problem. The harder half is that a firewall aggressive enough to catch everything will also block legitimate customers, and the version of this product that gets switched off after three weeks is always the one that blocked a real order.

So this is about what the technology actually does, where it genuinely helps, and the evaluation criteria that matter more than a detection percentage.

What it inspects and what it can decide
What it genuinely catches
False positives are the whole ballgame
Criteria worth evaluating
The order to do things in
How this fits the rest of the stack
FAQ

What it inspects and what it can decide

The firewall sits between the internet and your application, reading each request: the method, the path, the headers, the query string, the cookies and the body. It compares those against a rule set and decides to allow, block, log or challenge.

Rules come in three broad kinds, and knowing which is firing matters when you are debugging.

Signature rules. Pattern matches for known attack shapes: SQL injection fragments, script tags in parameters, path traversal sequences, known scanner user agents. Fast, well understood, and easy to evade with encoding tricks.
Managed rule sets. Vendor-curated collections, usually anchored on the OWASP core rules, updated as new attacks appear. This is what you get out of the box and where most value lives.
Custom rules. Your own logic: rate limits on specific paths, geographic restrictions, allowing only certain methods on an endpoint, blocking a specific pattern you have observed.

The important limitation to hold onto: the firewall reads requests, so it can only block what looks wrong. It cannot know that a request is authorised, that an identifier belongs to a different tenant, or that a valid-looking parameter will cause your code to do something expensive. Those are application bugs and no rule set catches them.

What it genuinely catches

The realistic value is real but narrower than the marketing suggests. Three things it does well.

Automated scanning noise. The constant background of bots probing for known vulnerable paths, old plugin exploits and default admin panels. A firewall removes almost all of it from your logs, which is worth something on its own because it makes the remaining logs readable.

Virtual patching. When a vulnerability lands in a framework or plugin you use, a rule blocking exploitation buys you time to update properly. For a large WordPress estate this alone can justify the product, because the window between disclosure and mass exploitation is now measured in hours.

Rate limiting and bot management. Credential stuffing, scraping and application-layer denial of service are handled here, and this is frequently the feature people actually use daily rather than the signature matching.

What it does not catch, stated plainly: business logic flaws, broken access control, a missing tenant check, an authenticated user doing something they should not be allowed to do, or an expensive query triggered by an entirely valid request.

False positives are the whole ballgame

This is the criterion that decides whether you still have a firewall in six months, and it is the one comparison charts handle worst.

Managed rule sets flag things that look like attacks. Real applications produce traffic that looks like attacks. A content management system where editors paste HTML, a support form where customers paste error messages containing SQL, a code snippet field, an address line with an apostrophe: each of these has taken down a legitimate workflow somewhere.

The pattern that actually works, and it is not optional:

Deploy in log-only mode. Block nothing. Let it run against real production traffic.
Run for at least two weeks, ideally through a full business cycle including whatever your monthly process is.
Review everything it would have blocked. Expect legitimate traffic in that list, and expect to be surprised by which endpoint.
Tune: disable rules producing noise on specific paths, add exclusions for the fields that legitimately contain odd content.
Move to blocking one rule group at a time, not all at once.
Keep watching. Application changes create new false positives, and a rule that was fine last quarter breaks the new feature.

Skipping the log-only phase is the single most common way this project fails. Blocking mode on day one produces a support incident within a week, and the fix under pressure is nearly always to turn the whole thing off.

Criteria worth evaluating

Assuming the detection rates are broadly comparable, which they usually are, these are the things that differ meaningfully.

Log-only mode with per-rule reporting. Non-negotiable. If you cannot see exactly which rule would have blocked which request, you cannot tune.
Exclusion granularity. Can you disable one rule for one parameter on one path, or only whole rule groups globally? This single capability decides how much legitimate traffic you end up allowing through to avoid breaking a form.
Latency added. Inspection costs milliseconds. Measure it on your own traffic rather than trusting a published figure.
Rule update cadence for new disclosures. The value of virtual patching is entirely a function of how fast a rule appears.
Rate limiting depth. Per-endpoint, per-account and per-address, or one global limit? The difference matters more than most of the signature features.
Log export. If the events cannot reach your own log store, you will not investigate them.
Pricing model. Per request, per site, or bundled. Per-request pricing during an attack means the attack costs you money, which is worth understanding in advance.

The order to do things in

A firewall is a mitigation layer, and layering it over an application with known problems produces a false sense of resolution. The sequence that produces actual security:

Fix the application. Parameterised queries, output encoding, tenant checks on every resource endpoint, dependencies updated. These eliminate vulnerability classes rather than filtering attempts at them.
Reduce exposure. Nothing public that does not need to be, databases on private networking, admin surfaces behind authentication.
Rate limit the expensive paths, which is cheap and stops the most common realistic attack.
Then add a firewall for the scanning noise, the virtual patching and the bot management.

The reduce-exposure step is worth more than it sounds. A deployment where the application is reachable only through the platform’s routing and the database only over private networking has far less to defend than a server with a public address and several open ports. The database network security docs cover that on RunxBuild, and it is the kind of default that removes a risk rather than filtering it.

How this fits the rest of the stack

Security spending is easiest to justify when it sits in a budget alongside everything else the deployment costs, because a firewall subscription competes with the same money as the plan size and the bandwidth. The RunxBuild hosting calculator prices those parts, which makes it easier to decide how much of the remaining budget belongs at the edge and how much belongs in fixing the application underneath.

Useful related references:

FAQ

What does a web application firewall actually block?

Requests matching known attack patterns: SQL injection fragments, cross-site scripting payloads, path traversal, known scanner signatures, and traffic exceeding your rate limits. It cannot block an attack that looks like a legitimate request, which includes broken access control and business logic flaws.

Will a WAF break my site?

It can, and this is the main risk. Managed rule sets flag content that resembles attacks, and real applications produce such content: pasted HTML in a CMS, error messages in support forms, code snippets, apostrophes in names. Always deploy in log-only mode for a couple of weeks and tune before blocking anything.

Is a WAF a substitute for fixing vulnerabilities?

No. It is a filter in front of the problem, useful for buying time when a disclosure lands and for removing scanning noise. A parameterised query eliminates SQL injection; a firewall rule attempts to recognise it. Fix the application first, then add the layer.

Does a WAF slow down my site?

It adds inspection latency, typically small but measurable, and the figure depends on rule count and request body size. Measure it against your own traffic rather than trusting a published number, and pay particular attention to large POST bodies, where inspection cost is highest.

What is virtual patching?

Deploying a firewall rule that blocks exploitation of a newly disclosed vulnerability before you have applied the actual fix. It is genuinely valuable because mass exploitation now often begins within hours of disclosure, and it is a temporary measure rather than a replacement for updating.