Peakhour.IO - WAAP

When and Why to Use a WAF: A Guide for WAF Sceptics

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

There are two popular opinions about web application firewalls.

The first is that every public application needs one. Turn it on, enable the managed rules and enjoy protection from the OWASP Top 10, zero-days, bots and DDoS attacks.

The second is that WAFs are expensive regex machines. They block customers, miss clever attacks and give management a green tick while the application remains vulnerable.

The second group has better jokes. Neither group has the whole answer.

A WAF is useful when it is given a job it can actually perform. It is disappointing when it is expected to understand an application better than the people who built it.

The practical question is not “do WAFs work?” It is: which risks can this WAF reduce, what will it never understand, and who will operate it when the application changes?

What a WAF can see

A traditional WAF sits in the HTTP request path. It inspects requests and applies managed or custom rules before passing allowed traffic to the application.

That position gives it a useful but limited view.

It can see paths, methods, headers, cookies, query strings and supported request bodies. Depending on the product, it may also have access to IP reputation, network characteristics, bot signals, rate history and API schemas.

It cannot naturally see the full business meaning of the request.

The WAF may know that a customer requested /api/invoices/123. The application knows whether that customer owns invoice 123. The WAF may see 200 valid checkout requests. The application knows whether they represent a wholesaler, a scalper or a broken integration.

That boundary explains both the value and the frustration.

The criticism is mostly fair

WAF sceptics are right about several things.

A determined attacker can bypass generic detection. Differences in encoding and HTTP parsing can cause a WAF and an application to interpret the same request differently. A 2024 study found 311 protocol-level evasion cases across 14 WAFs and 20 web frameworks.

False positives are real too. Legitimate HTML, JSON, support messages or product descriptions may resemble an attack signature. Microsoft recommends introducing a WAF in detection mode, reviewing logs and tuning it before blocking. It says this process may take several weeks.

A WAF also cannot fix insecure application logic. It cannot repair broken object-level authorisation, make password recovery safe or decide whether a valid-looking transaction is fraudulent. Those controls belong in the application.

And, yes, putting anything inline creates another dependency. A poor rule can block real customers. A provider can have an outage. A self-hosted appliance can fail open or fail closed.

These are reasons to be precise about the job. They are not reasons to send every internet request directly to the origin.

Buying time during a patch window

The best reason to have a WAF is rarely mentioned on the product page. It buys time.

When a serious vulnerability appears, the correct response is to fix the affected software. But finding every instance, testing the patch and deploying it safely may take hours or days. Third-party and legacy applications can take longer.

A virtual patch can narrow that exposure window. A custom rule may block the vulnerable path, reject a malicious parameter or detect the request pattern associated with the exploit while the real patch is prepared.

OWASP's virtual patching guidance is clear about the boundary: correcting the source is the preferred remediation. The WAF rule is a compensating control, not permission to leave the vulnerability in place.

That still makes it valuable. During an incident, ten minutes and two days are very different amounts of exposure.

Stopping expensive requests earlier

Applications are expensive places to reject bad traffic.

By the time a request reaches application code it may have consumed a connection, invoked authentication, queried a database, called another API or triggered a paid service. A request does not need to contain an obvious exploit to create cost. It may simply repeat an expensive operation far more often than a legitimate user would.

An edge control can reject common exploit traffic and excessive requests before that work happens.

This is especially useful for login, search, registration, password reset, checkout and expensive API routes. Rate limits and bot controls can respond differently based on route, session, account outcome and other available evidence instead of treating every request from an IP address as the same actor.

NIST recommends applying general WAF, bot and denial-of-service controls early in the API serving stack to protect upstream systems from malicious payloads and unrestricted resource consumption. It also treats those as separate capabilities.

That distinction matters. A classic WAF does not automatically provide sophisticated bot management or network-scale DDoS protection. A broader WAAP service may bundle them, but buyers should check the controls rather than trust the acronym.

A control you can reach during an incident

Security incidents create awkward gaps between knowing there is a problem and having the final fix ready.

Perhaps one endpoint is being abused. A new exploit is spreading. Login failures are climbing. A scraper is rotating through residential proxies. An old hostname that should have disappeared is suddenly receiving traffic.

A centrally managed WAF gives the operations team somewhere to make a narrow, reversible change without waiting for several application releases. They can restrict a route, add a virtual patch, change a rate limit, challenge suspicious traffic or collect more detailed events while the investigation continues.

That operational separation is valuable. The application team can work on the root cause while the security or operations team reduces immediate exposure.

It also needs discipline. Emergency rules require owners and expiry dates. A temporary exclusion should not survive for years. Changes should be observed before blocking where the situation allows it.

Evidence before the origin

A WAF is often discussed only as a blocking device. Its position in the request path can be just as useful for understanding what is happening.

Good events can show which route was targeted, which rule matched, what action was taken and whether the request reached the origin. Rate, bot and API signals can add context. Combined with application logs, this helps teams distinguish an attack from a customer problem, a broken integration or a badly tuned rule.

The same visibility can expose weaknesses in the deployment itself:

a forgotten API version receiving traffic;
a hostname missing the expected policy;
an origin that is still publicly reachable;
an endpoint whose cost makes it an easy denial-of-service target;
an exclusion that is much broader than anyone remembered.

This does not require blocking on day one. Observe mode can create value before the team is confident enough to enforce a decision.

When the case for a WAF is strong

A WAF is usually worth serious consideration when the application has several of these characteristics:

customer accounts, payments or personal information;
public APIs or expensive dynamic routes;
third-party, legacy or slow-to-patch software;
regular scanning, credential stuffing, scraping or automated abuse;
multiple applications that need consistent emergency controls;
compliance requirements for runtime web protection;
an operations team able to tune rules and investigate events.

PCI DSS provides one concrete example. Since 31 March 2025, Requirement 6.4.2 requires an automated technical solution in front of applicable public-facing web applications to continually detect and prevent web attacks. The PCI Security Standards Council describes the requirement without requiring a particular product called a WAF.

Compliance is a legitimate reason to deploy the control. It is not evidence that the deployment works.

When the case is weak

Not every website needs a large WAAP contract.

A genuinely static, low-value site with no accounts, API or meaningful dynamic input presents a smaller application attack surface. Basic CDN protection, origin restriction, good patching and sensible security headers may be enough.

The case is also weak when nobody will own the WAF. An ignored ruleset eventually becomes noisy, stale or full of broad exclusions. A dashboard that nobody checks is not defence in depth.

Be cautious when the proposed product does not match the actual problem. A signature WAF is not the complete answer to sophisticated bots. An on-premises appliance cannot absorb a volumetric attack larger than its internet connection. Edge rules cannot repair business logic. A provider's “AI-powered” label does not establish an acceptable false-positive rate.

Sometimes the right answer is a smaller control. Sometimes it is a different control. The point is to buy against the risk rather than the category name.

How not to become the WAF horror story

Most bad WAF experiences begin with the same mistake: enabling everything and immediately blocking production traffic.

A safer deployment looks less exciting:

Define the job. Decide which applications, routes and abuse cases the WAF is expected to cover.
Put all relevant traffic through it and restrict direct access to the origin.
Start managed rules and new controls in observe or count mode.
Review real production-shaped traffic and tune false positives narrowly.
Test login, checkout, uploads, APIs and other important customer journeys before enforcement.
Give every custom rule and virtual patch an owner, reason and review date.
Monitor allowed as well as blocked traffic so false negatives do not disappear from view.
Keep application-level authorisation, validation and rate controls in place.
Test what happens when the WAF, agent or provider is unavailable.

That is the difference between owning a control and merely paying for one.

Where this leaves us

A WAF is neither useless nor sufficient.

It cannot understand every valid-looking abuse, prevent every bypass or rescue an application that ignores secure design. It introduces cost, tuning and another inline dependency.

It can still stop a great deal of cheap hostile traffic, buy time during a vulnerability, prevent excessive work from reaching the origin, give operators a fast response point and leave evidence that helps explain an incident.

Our two companion articles make each side of the case directly: Everyone Says a WAF Is Useless. Are They Right? and Your Application Needs a WAF. Just Not for the Reason You Think.

The conclusion is less catchy than either headline. Use a web application firewall when the application has something worth protecting, the WAF has a defined job and someone is responsible for operating it. Then keep fixing the code behind it.

Your Application Needs a WAF. Just Not for the Reason You Think

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

A web application firewall will not make bad code good.

It will not repair broken access control. It will not redesign an unsafe checkout. It cannot decide whether a customer should be allowed to see a particular invoice, transfer money from an account or buy the last 200 tickets to a concert.

If your public application has accounts, valuable APIs or expensive dynamic routes, you probably still need one.

The case has nothing to do with an invisible shield or a promise to “solve the OWASP Top 10”. Public applications meet hostile traffic every day, software is imperfect and fixing the right thing often takes longer than attacking it.

That is what a WAF is for.

The internet does not wait for your next release

Every public application receives traffic it did not ask for.

Some of it is harmless background noise: crawlers looking for software that is not installed, scripts requesting old WordPress paths, scanners testing yesterday's vulnerability against every address they can find.

Some of it is aimed directly at the application: SQL injection attempts, malicious uploads, path traversal, unusual encodings and requests crafted to trigger a known vulnerability.

The application can reject those requests itself. Ideally, it will. But allowing every request to reach application code, authentication services, databases and third-party APIs is an expensive way to discover that something is hostile.

A WAF creates an earlier decision point. It can discard common exploit traffic before the request reaches the part of the system that holds customer data or performs expensive work.

That does not make the application secure. It means the application no longer has to face every cheap attack on its own.

Patches take time. WAF rules take less

The clearest reason to run a WAF is virtual patching.

Suppose a serious vulnerability appears in a framework, CMS plugin or third-party product. The responsible answer is to patch it. But first the team has to identify every affected system, test the update, work around compatibility problems and arrange a safe deployment.

The attacker does not have to do any of that.

A targeted WAF rule can reduce the exposure while the real patch is prepared. It may block a particular path, parameter, payload or request shape associated with the exploit. It is not the final repair, but it can turn an open window into a much narrower one.

OWASP's virtual patching guidance is refreshingly practical about this. Fixing the source is the number-one technical remediation. A virtual patch is useful when that fix cannot happen immediately. The two controls are complementary, not rivals.

This matters most for legacy applications, third-party software and systems with slow release cycles. Those are exactly the places where “just fix the code” can be correct advice and an inadequate incident response.

Your application should not absorb unlimited work

Not every damaging request contains an obvious attack string.

A search request may be perfectly valid but expensive. A login attempt may fail normally while being one of a million credential-stuffing attempts. A scraper may request public pages exactly as a browser would, just much faster. A customer-facing API may trigger email, SMS, payment or database costs every time it is called.

This is where a modern WAAP service goes beyond a traditional signature WAF. Rate limiting, bot management and application-layer DDoS controls can make decisions based on the route, request rate, account outcome, browser or network evidence, and the work the origin is being asked to perform.

NIST recommends placing general WAF, bot and denial-of-service controls early in the API serving stack so malicious payloads and unrestricted resource consumption do not exhaust upstream systems. Importantly, NIST treats these as related but separate capabilities. Buying something called a WAF does not automatically mean all three are present.

Reject bad or excessive work before it becomes expensive work.

Put the checks in different places

Good application security is built in layers because each layer knows something different.

The application knows who owns an object, whether an account may perform an action and what a valid transaction looks like. It should remain authoritative for those decisions.

The edge sees different evidence. It can compare traffic across routes and hosts, recognise widespread exploit patterns, apply an emergency rule across several applications and notice that one client is creating an unusual amount of work before the request reaches the origin.

Neither view is complete.

A WAF is valuable because it is independent of the code it protects. If an application developer makes a mistake, the WAF may still reject the exploit. If a WAF misses a clever request, the application should still validate it. One control can fail without immediately making the failure fatal.

If either layer makes a mistake, the other still gets a chance to respond. That is the useful part of defence in depth.

It gives you somewhere to respond

During an incident, speed matters.

Teams often know enough to reduce the risk before they know enough to ship the final fix. They may need to restrict a vulnerable endpoint, block an exploit pattern, lower a rate limit, challenge suspicious login traffic or temporarily exclude a region where an attack is concentrated.

Doing that through application releases can be slow, especially when several services are affected. A centrally managed WAF gives operators somewhere to make a narrow, reversible change while the application teams investigate.

The words “narrow” and “reversible” matter. Emergency blocks need owners and expiry dates. Rules should be tested in observe mode where time permits. Broad exclusions created during the incident should not quietly become permanent architecture.

The WAF is useful here because it is an operational control, not because it knows more about the application than its developers do.

It leaves evidence at the front door

Prevention gets most of the attention, but visibility is one of the better reasons to have a WAF.

When an application behaves strangely, the team needs to know what arrived before the failure. Which routes were targeted? Were requests blocked or allowed? Did the traffic share a network, client pattern or payload? Was a rate limit crossed? Did the attacker reach the origin directly?

Useful WAF events can answer part of that story. Combined with origin and application logs, they help distinguish a real attack from a broken integration, a customer mistake or a badly tuned rule.

They can also reveal traffic that nobody knew was public: an old API version, forgotten hostname, administrative route or direct-origin path.

Logs are not automatically useful. A million unexplained rule matches can be worse than a smaller set of events tied to route, action and outcome. But without evidence at the entry point, incident response starts with a large blind spot.

Compliance is a reason, but not the best one

For organisations handling payment-card data, a runtime application control may not be optional. Since 31 March 2025, PCI DSS Requirement 6.4.2 requires an automated technical solution in front of applicable public-facing web applications to continually detect and prevent web attacks.

The PCI Security Standards Council describes the requirement without mandating a particular product called a WAF.

That distinction matters. Compliance can justify the control, but it does not prove the control is effective. A WAF in log-only mode with nobody reading the alerts is not much of a defence. Neither is one with a public origin that attackers can reach directly.

Passing an audit is a business requirement. Blocking useful attacks without blocking customers is the security requirement.

A WAF needs to be operated, not merely purchased

The case for a WAF comes with a condition: somebody has to own it.

Managed rules need to be introduced carefully. Legitimate traffic needs to be observed. False positives need narrow corrections rather than sweeping allowlists. Important customer journeys need tests. Virtual patches need to be removed after the underlying vulnerability is fixed. Origins need to be locked down so the edge cannot be bypassed.

The job is not finished when the DNS changes.

The right first step is often detection rather than immediate blocking. Learn what normal traffic looks like, identify the noisy rules, find missing hostnames and understand which requests are expensive. Then move well-understood controls into enforcement.

A badly operated WAF can block customers, miss attacks and create false confidence. That is a reason to operate it properly, not a reason to give the application no independent protection at all.

What a WAF is actually for

A WAF should make exploitation harder, give operators a faster response and reduce what reaches the origin. In practice that means stopping familiar attack traffic, buying time during a vulnerability, putting limits in front of expensive routes and recording enough evidence to explain what arrived.

Developers still own secure design. The WAF gives them another layer, not an exemption.

Our companion article, Everyone Says a WAF Is Useless. Are They Right?, takes the sceptical case seriously. WAFs can be bypassed. They can cause false positives. They create cost and another inline dependency.

Those are real constraints. They define how a web application firewall should be deployed and judged.

They do not change the basic reality: bugs happen, patches take time and bots are cheap. It is sensible to make hostile traffic cross one more independent decision point before it reaches the application.

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.