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.
