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.
