A WAF is one layer of defense, not a substitute for secure code — but it's a genuinely effective layer that stops a large share of automated attacks before they ever reach your application.
Most attacks a public-facing web application sees aren't sophisticated, targeted intrusion attempts — they're automated scanners probing for known vulnerabilities, credential-stuffing bots trying leaked password lists against a login form, and scripted SQL injection attempts fired at every URL parameter that looks like it might touch a database. A Web Application Firewall (WAF) exists specifically to filter this category of traffic out before it reaches your application code, and understanding what it actually does — and doesn't do — is the difference between deploying one as real protection and deploying one as a false sense of security.
We set up and configure WAFs as part of hardening client sites and applications, usually through the cloud and CDN providers already in a project's stack rather than standalone hardware. Here's what a WAF actually protects against, how it works, and where its limits are.
What a WAF Actually Does
A WAF sits between incoming traffic and your web application, inspecting each HTTP request against a set of rules before deciding whether to let it through, block it, or challenge it (with a CAPTCHA or similar). Unlike a traditional network firewall, which filters traffic based on IP addresses and ports, a WAF inspects the actual content of a request — the URL, query parameters, headers, cookies, and request body — looking for patterns associated with known attack techniques.
This makes it fundamentally an application-layer (Layer 7) defense, positioned to catch attacks that a network firewall has no visibility into, since a network firewall sees that a request is going to port 443 over HTTPS but has no way to inspect what's actually inside that encrypted, application-level payload once it's terminated.
The Attack Categories a WAF Is Built to Catch
The OWASP Top 10 — a widely referenced, regularly updated list of the most critical web application security risks — maps closely onto what WAF rule sets are designed to catch:
- SQL injection — attempts to insert malicious SQL through form fields or URL parameters to manipulate or extract data from a backend database. A WAF's rules recognize common SQL injection patterns (unexpected quotes,
UNION SELECTpatterns, comment sequences) in request content and block them before they reach the application. - Cross-site scripting (XSS) — attempts to inject malicious JavaScript into a page that other users will later load, often through comment fields, search boxes, or any input that gets rendered back to other users without proper sanitization. WAF rules look for script tags and JavaScript event handler patterns in submitted content.
- Cross-site request forgery (CSRF) and session-based attacks — patterns indicating a request is being made from an unexpected origin or replaying a stolen session token.
- Known CVE exploitation attempts — automated scanners regularly probe for specific, publicly disclosed vulnerabilities in common CMS platforms, plugins, and frameworks. A managed WAF's rule set is updated as new CVEs are disclosed, blocking exploitation attempts against vulnerabilities that may not yet be patched in your specific installation.
- Bad bots and scraping — traffic identified as automated (through behavioral signals, known bad user agents, or missing browser fingerprint characteristics typical of real browsers) attempting to scrape content, test stolen credit card numbers, or scan for vulnerabilities at scale.
Rate Limiting and Bot Protection
A significant share of a modern WAF's practical value isn't in recognizing a specific attack signature — it's in rate limiting and bot management. Credential stuffing (testing large lists of leaked username/password combinations against a login endpoint) and brute-force attacks don't necessarily look malicious in any single request; what makes them identifiable is volume and pattern — hundreds of login attempts from a small pool of IP addresses in a short window, or requests arriving with none of the timing variance a real human typing into a form would show.
Modern WAFs (Cloudflare, AWS WAF, and similar) combine signature-based rule matching with rate limiting and behavioral bot detection, which is often the more consequential protection for a typical business site — most real-world attacks against small and mid-size sites are automated and volume-based rather than a targeted, manually-crafted exploit.
Managed Rule Sets vs Custom Rules
Most teams shouldn't write WAF rules from scratch. Cloud WAF providers (Cloudflare, AWS WAF, Azure's equivalent) ship managed rule sets — pre-built, continuously updated rules covering the OWASP Top 10 and known CVEs, maintained by the provider's security research team, which is both more comprehensive and better maintained than what an individual team is likely to build and keep current on their own.
Custom rules layer on top for application-specific logic — blocking traffic to an admin path from outside a known IP range, rate-limiting a specific API endpoint more aggressively than the rest of the site, or blocking requests matching a pattern specific to an attack your site is actually seeing in its logs. The practical approach is starting with a managed rule set in a monitoring/logging mode, reviewing what it would have blocked over a period of real traffic, then moving to active blocking once you've confirmed it's not flagging legitimate traffic — and adding custom rules only for patterns specific to your application that the managed set doesn't cover.
False Positives Are the Real Operational Cost
The most common reason a WAF gets disabled or set to "log only" permanently isn't that it fails to catch attacks — it's that overly aggressive rules start blocking legitimate users. A rule tuned to catch SQL injection might flag a legitimate user whose search query happens to contain a word pattern the rule matches on; a rule meant to catch script injection might flag a content management system's own rich-text editor submitting legitimate HTML.
This is why deploying a WAF isn't a one-time "turn it on" event — it needs a tuning period where rules run in monitoring mode against real traffic, false positives get identified and excluded, and only then does active blocking mode make sense for a given rule set. Skipping this step is how a WAF ends up either blocking real customers (and getting disabled in a panic) or running in permanent monitor-only mode, providing much less actual protection than it could.
What a WAF Does Not Do
This is the part vendors gloss over and the part that matters most for setting realistic expectations. A WAF is not a substitute for secure application code:
- It doesn't fix a SQL injection vulnerability — it reduces the odds that a generic, automated attack pattern reaches the vulnerable code path. A sufficiently targeted attacker crafting a request specifically to evade the WAF's rule patterns while still exploiting the underlying flaw can still succeed if the flaw itself is never fixed.
- It doesn't protect against business-logic flaws — a checkout flow that lets a user apply the same discount code unlimited times, or an authorization bug that lets a logged-in user access another user's data by changing an ID in the URL, look like completely legitimate requests to a WAF, because nothing about the request's content is malicious in the way the WAF is trained to detect. These require actual code-level fixes and proper authorization checks, not a filtering rule.
- It doesn't replace secure coding practices, dependency updates, or a real patching cadence. A WAF buys time and reduces exposure against known, generic attack patterns; it doesn't make an unpatched, vulnerable dependency safe to leave unpatched indefinitely.
The accurate mental model: a WAF is one layer in a defense-in-depth strategy, sitting alongside secure coding practices, dependency scanning, regular patching, and proper authentication and authorization logic — not a replacement for any of them.
Where a WAF Actually Sits: Deployment Models
A WAF can be deployed in a few different places, and which one fits depends on what infrastructure a site already runs on. A CDN-integrated WAF (Cloudflare, Fastly, and similar) inspects traffic at the network edge, before it ever reaches your origin server — the simplest option for most sites, typically requiring only a DNS change to route traffic through the provider, and with the side benefit of blocking malicious traffic before it even consumes your server's bandwidth or compute. A cloud-provider WAF (AWS WAF, Azure's equivalent) integrates directly with that provider's load balancer or API gateway, a natural fit for an application already hosted entirely on that cloud. A reverse-proxy WAF (ModSecurity running on an Nginx or Apache instance you manage yourself) offers the most control and is fully self-hosted, at the cost of needing your own team to maintain and update the rule set — a reasonable choice for organizations with specific compliance requirements around data residency or a strong preference against routing traffic through a third party, but a real ongoing maintenance commitment compared to a managed option.
For most business websites and applications, a CDN-integrated or cloud-provider WAF is the practical default: the rule sets are maintained by a dedicated security team at the provider, updates for newly disclosed vulnerabilities roll out automatically, and the setup cost is measured in hours rather than the ongoing weeks of a self-managed reverse-proxy deployment.
Getting Started Practically
For most business websites and web applications, the pragmatic path is enabling the managed rule set already available through whichever CDN or cloud provider is in front of the site (Cloudflare's WAF, or AWS WAF if the application already sits behind AWS infrastructure, are common starting points), running it in monitoring mode for one to two weeks against real traffic, reviewing what it flagged, and then switching the well-tested rule categories to active blocking. Rate limiting on login and any form-submission endpoints is worth enabling from day one, since credential stuffing and form spam are close to universal problems regardless of what the application does.
The Practical Takeaway
A WAF is genuinely effective against the high-volume, automated share of attacks that every public-facing site sees regardless of its size or profile — and for most businesses, that's the majority of actual attack traffic they'll encounter. It is not, and shouldn't be sold or understood as, a fix for insecure code or business-logic flaws underneath it. The right posture is treating a WAF as one deliberately tuned layer in a broader security practice — alongside secure coding, dependency hygiene, and proper authorization checks — rather than a single control a business can turn on once and consider its web security handled.
