Everyone Says a WAF Is Useless. Are They Right?

2026-07-28T09:00:00+10:00

Spend long enough around application security and someone will tell you that web application firewalls are useless.

They are easy to bypass. They block real customers. They cannot fix bad code. They cost money, need constant tuning and create one more thing that can fail.

The annoying part is that none of this is entirely wrong.

The mistake is jumping from “a WAF is imperfect” to “a WAF has no useful job”. A lock can be picked. We still lock the door. Security controls are allowed to solve a bounded problem.

So here are ten excellent reasons not to use a WAF—and what they really tell us.

1. “We write secure code”

Good. Keep doing that.

A WAF cannot repair broken access control, fix an insecure password reset flow or stop an application from selling the same scarce ticket twice. Those rules belong in the application because the application understands the customer, the object and the transaction.

But even good teams ship bugs. Dependencies develop vulnerabilities. A vendor patch can take days to test. A legacy application may not have a team at all.

This is where virtual patching earns its keep. A narrowly written WAF rule can block a known exploit while the real fix is prepared. OWASP describes the source-code fix as the preferred answer, while also recognising that an enforcement layer can reduce the exposure window.

Secure code and a WAF are not competing ideas. One fixes the weakness. The other can make it harder to exploit in the meantime.

2. “Attackers can bypass it”

They can.

Researchers have found WAF bypasses using alternative encodings, duplicated parameters and differences between the way a firewall and an application parse the same request. One 2024 study found 311 protocol-level evasion cases across 14 WAFs and 20 web frameworks.

That finding should end any talk of a WAF as a force field. It should not convince us to pass every request straight to the application.

Most hostile internet traffic is not a handcrafted masterpiece. It is scanning, probing and replaying familiar attacks across thousands of sites. Filtering that traffic does not make the application invulnerable. It removes a large amount of cheap, automated opportunity.

A determined burglar may pick a lock. We still lock the door.

3. “WAFs block legitimate customers”

An untuned WAF certainly can.

A product description, support ticket or API request may contain HTML, SQL-like text or unusual characters for perfectly innocent reasons. Turn every managed rule on, switch immediately to blocking mode and the first security incident may be your own checkout failing.

Microsoft recommends starting a new WAF in detection mode, reviewing the logs and tuning it before enforcement. It also says the process may take several weeks.

What this rules out is the Friday-afternoon deployment: every managed rule enabled, blocking turned on and nobody watching checkout.

Start by observing. Find the rules that match real traffic. Make exclusions as narrow as possible. Test important customer journeys. Then block what you understand.

4. “It cannot understand our business”

Correct. This may be the most important criticism on the list.

A generic WAF cannot know that customer A should never see customer B's invoice. It cannot know whether buying 400 concert tickets is normal wholesale activity or scalping. It cannot decide whether a bank transfer fits the customer's history.

Many serious API failures involve valid-looking requests used in the wrong context. The OWASP API Security Top 10 is full of problems involving object ownership, authentication, permissions, resource consumption and sensitive business flows.

Those controls need application context.

There is still work suited to the edge: reject malformed requests, enforce broad limits, filter known exploit patterns and record what reached a sensitive route. A wider WAAP service may also add API schemas, bot signals and account-abuse controls. The application remains responsible for the final business decision.

5. “We already have a CDN”

You may already have the machinery for a WAF. That does not mean it is protecting anything.

Is the managed ruleset enabled? Is it logging or blocking? Does it cover every public hostname and API version? Can an attacker connect directly to the origin? Are large or compressed request bodies inspected? Has anyone reviewed the exclusions since the last application release?

A WAF only protects traffic that passes through it. Cloudflare's own troubleshooting guide says it only mitigates proxied traffic. AWS separately documents how to restrict an origin so visitors cannot bypass CloudFront and reach it directly.

“We have a CDN” is an architecture statement. “All public traffic crosses an active, tested policy” is a security statement.

6. “A WAF will not stop a huge DDoS attack”

Also true.

If an attack fills the network connection in front of an on-premises WAF, the appliance may be functioning perfectly while the website remains unreachable. Volumetric attacks need upstream capacity: an ISP, cloud network, CDN or dedicated scrubbing service able to absorb them before they reach the constrained link.

Application-layer attacks are different. They target expensive searches, login endpoints, uncached pages, GraphQL queries or API operations that consume disproportionate origin resources. Rate limits and request-aware controls can help there.

This is why the distinction between WAF and WAAP matters. A classic WAF filters HTTP requests. A WAAP bundle may combine that with bot management, API protection and application-layer DDoS controls. The acronym does not tell you which controls are included, licensed or switched on.

7. “Bots just rotate their IP addresses”

Yes, and an IP blocklist on its own is a fairly tired answer.

Modern abuse can arrive through residential proxies, mobile networks, cloud platforms and large pools of short-lived addresses. If the only question is “have we seen this IP before?”, the attacker often wins by changing it.

Useful bot management combines several weaker signals: request rate, route, session behaviour, account outcome, headers, network characteristics and browser evidence. The response can vary too. A suspicious request might be logged, slowed, challenged or given a tighter limit instead of being permanently blocked.

OWASP's bot-management guidance makes the goal clear: raise the cost of abusive automation while leaving legitimate people and useful bots alone.

An IP list is easier. It is also further from the problem.

8. “It is another expensive security subscription”

Sometimes it is. WAF pricing can be a peculiar experience because a business may pay to inspect millions of requests it never wanted.

The fair comparison is not “WAF bill versus zero”. It is the WAF bill against origin compute, emergency engineering, fraud, scraping, support calls, application downtime and the cost of investigating an incident with poor logs.

That does not guarantee the WAF wins. A brochure site with no accounts, no API and almost no dynamic input may need little more than sensible CDN protection, origin restriction and good patching. A busy login or checkout path under constant automated abuse has a different calculation.

The control should match the exposure. Buying the largest WAAP bundle available is not a security strategy.

9. “It is not set-and-forget”

No useful security control is.

Applications change. New endpoints appear. Old APIs stay online longer than expected. Managed rules are updated. Attack traffic changes. An exclusion created during an incident quietly survives for three years.

A WAF needs an owner, observable decisions, staged changes and periodic review. Virtual patches need expiry dates. Important customer journeys need regression tests. Logs need someone who will look at them.

If nobody will operate the WAF, that is a legitimate reason not to buy an elaborate one. A permanently ignored dashboard is not defence in depth. It is interior decoration.

10. “Putting it inline creates another point of failure”

It does.

A bad rule can block a site globally. A provider can have an outage. A self-hosted appliance can fail open or fail closed. In 2019, Cloudflare published a detailed account of how a WAF rule containing a poorly performing regular expression exhausted CPUs across its network.

Inline controls need the same engineering discipline as the applications behind them: staged rollout, rollback, monitoring, tested failure modes and a clear way to recover.

The origin, load balancer, DNS provider, identity service and database are points of failure too. We accept those dependencies when the service is worth it, then engineer around their failures. A WAF deserves the same treatment.

So, do you need a WAF?

Maybe not.

If the site is genuinely static, low value and already protected by a capable edge, a premium WAAP service may solve very little. If nobody will tune it, test it or respond to its alerts, the product may create more confidence than protection.

The case becomes much stronger when the application has accounts, payments, personal information, valuable APIs, third-party dependencies, slow patch cycles or a history of automated abuse. It becomes stronger again when the same edge can protect the origin, control bots, limit expensive routes and leave useful evidence for the people investigating incidents.

A web application firewall does not make an insecure application secure. The honest claim is smaller: applications have bugs, patches take time and the public internet is noisy. A well-run WAF gives that noise one more place to stop before it becomes your application's problem.

Peakhour.IO - DDoS Protection