What do a scrappy WordPress blog, a global bank, and a Kubernetes-native startup have in common? All three can get flattened by the same class of attack, and all three probably rely on a web application firewall (WAF) to stop it. The interesting part isn’t that WAFs exist. It’s how wildly different the actual deployments look in practice.
This article walks through concrete web application firewall examples, from open-source engines you run yourself to managed cloud services that sit in front of millions of sites. Along the way, expect practical notes on what works, what quietly fails, and where teams waste money.
What Counts as a Web Application Firewall Example?
A WAF is a filter that inspects HTTP and HTTPS traffic and blocks requests that look malicious, typically SQL injection, cross-site scripting, path traversal, and bot abuse. The NIST guidelines on firewalls and firewall policy treat web application firewalls as a distinct firewall type, which is a useful framing: a WAF is not a network firewall with extra features. It understands application-layer semantics.
Examples fall into four rough buckets:
| Deployment type | How it works | Typical user |
|---|---|---|
| Open-source engine | Self-hosted module or reverse proxy | Sysadmins, DevOps teams |
| Cloud-managed WAF | Vendor runs the rules at the edge | SaaS companies, e-commerce |
| Appliance or virtual WAF | Hardware or VM in the data center | Enterprises, regulated industries |
| Cloud-native WAF | Attached to a load balancer or API gateway | Teams already on that cloud |
The bucket matters more than the brand. A managed edge WAF and a self-hosted engine solve the same problem with completely different operational costs.
Example 1: ModSecurity as a Self-Hosted Engine
ModSecurity is the closest thing the WAF world has to a household name. Originally developed by Ivan Ristić in the early 2000s, it has spent two decades as the default open-source option. It runs as a module for Apache and nginx, or as a reverse proxy filter, and it does one thing well: it gives you raw, inspectable control over request matching.
The catch is that ModSecurity is an engine, not a policy. Out of the box it does very little. You supply the rules, and that’s where most beginners stumble. A fresh install with no ruleset is essentially a logging tool.
Practical tip: if you’re new to this, don’t write rules by hand. Start with a maintained ruleset and tune from there. Hand-rolled regex rules are where careers go to die.
Example 2: OWASP Core Rule Set on Top of ModSecurity
The OWASP ModSecurity Core Rule Set (CRS) is the ruleset that makes ModSecurity useful. Maintained by the OWASP Foundation, it bundles generic attack detection for the categories in the OWASP Top 10, including SQL injection, cross-site scripting, local file inclusion, and remote code execution attempts.
The CRS is also a cautionary tale about false positives. In real deployments, the default paranoia level blocks legitimate traffic surprisingly often, especially admin panels, rich text editors, and anything that accepts HTML input. The standard fix is to start at paranoia level 1, run in detection-only mode for a week or two, log what fires, and only then switch to blocking.
Common mistake: teams enable blocking mode on day one, break a checkout flow, and then disable the WAF entirely. That’s worse than never installing it, because now everyone believes the site is protected.
Example 3: AWS WAF Attached to CloudFront
AWS WAF is a managed service that attaches to Amazon CloudFront, Application Load Balancers, and API Gateway. You define web ACLs (access control lists), stack managed rule groups from AWS and third-party vendors, and add custom rules for rate limiting or geographic blocking.
This is a good example of a WAF that fits teams already living in AWS. There’s nothing to patch, no engine to upgrade, and the ruleset updates arrive automatically. The tradeoff is that debugging gets abstract. When a request is blocked, you’re reading sampled logs rather than tailing a local error log, and sampling means you sometimes don’t see the request that broke production.
A practical pattern that works well: put a rate-based rule in front of your login endpoint first. Credential stuffing is the most common real-world attack most sites face, and a simple request-rate threshold kills a large share of it without touching your application logic.
Example 4: Cloudflare WAF at the Edge
Cloudflare WAF runs on Cloudflare’s edge network, which means traffic is filtered before it ever reaches your origin server. The managed rulesets cover the usual suspects, and there’s an option to run the OWASP Core Ruleset directly if you want the same detection logic as a self-hosted ModSecurity deployment.
The appeal is the setup time. Point your DNS at Cloudflare, enable the proxy, turn on managed rules, and you have protection in an afternoon. For small teams without a dedicated security engineer, that’s often the difference between having a WAF and not having one.
The tradeoff is control granularity. You get strong defaults and a decent rule editor, but you’re not writing raw engine rules. If your application has unusual traffic patterns, you’ll spend time on exceptions rather than fine-tuning detection.
Example 5: F5 Advanced WAF for Enterprise Data Centers
F5 BIG-IP Advanced WAF, formerly known as Application Security Manager, is the enterprise appliance example. It sits in front of applications in a data center, learns normal traffic patterns over time, and builds a positive security model: instead of blocking known-bad requests, it learns what legitimate requests look like and blocks everything else.
That approach shines in environments with stable, well-defined applications, like internal banking portals. It struggles with fast-moving consumer apps where the frontend ships changes weekly, because the learned model keeps going stale.
If you’re comparing this to network-layer filtering, it helps to understand what a firewall is and how it works at the packet level before evaluating an application-layer product. They solve different problems, and vendors sometimes blur the line in marketing materials.
Example 6: Imperva for Cloud and On-Premises Hybrids
Imperva offers both a cloud WAF and an on-premises appliance line, which makes it a common pick for organizations that need consistent policy across a data center and a public cloud footprint. The selling point is centralized management: one console, multiple enforcement points.
Hybrid deployments are where WAF projects usually get messy. Different enforcement points drift out of sync, exceptions get applied in one place and forgotten in another, and nobody can say with confidence which rules are actually live. If you go hybrid, treat policy as code and version it, or you’ll be reconciling rule sets by hand forever.
Example 7: Coraza as a Modern Open-Source Alternative
Coraza is a Go-based WAF engine that’s compatible with ModSecurity rules, including the OWASP CRS. It’s an OWASP project, and it’s designed for modern deployments: it embeds in Go applications and proxies rather than requiring an Apache or nginx module.
This is the example worth watching if you’re building cloud-native infrastructure. The old ModSecurity model assumes a traditional web server. Coraza assumes containers, sidecars, and APIs. Same detection philosophy, different packaging.
Example 8: WAFs Inside Cloud-Native API Gateways
Many teams don’t buy a WAF at all. They enable the WAF feature on their API gateway, which is often bundled with the platform they already pay for. It’s the least glamorous example and probably the most common one in practice.
The upside: no new vendor, no new deployment, one bill. The downside: WAF features inside gateways tend to be thinner than dedicated products, and rule customization is limited. For a small internal API, that’s fine. For a public-facing payment flow, it usually isn’t.
If you’re building agent-based systems that call APIs programmatically, the threat model shifts again. Understanding what an AI agent is, with examples and applications, helps explain why bot traffic now includes well-behaved automation that a naive WAF rule will block by accident.
How to Choose Between These Examples
The right WAF depends far less on feature matrices than on three questions.
First, who operates it? A two-person team should not run a self-hosted engine with custom rules. A platform team with on-call rotation absolutely can.
Second, where does traffic terminate? Edge-managed WAFs win when you’re already behind a CDN. Appliance WAFs win when traffic never leaves the data center.
Third, how often does the application change? Positive security models and strict rulesets punish fast release cycles. Managed rulesets with tuning tolerate them better.
A comparison that helps in practice:
| Priority | Best-fit example |
|---|---|
| Fastest time to protection | Cloudflare WAF or AWS WAF |
| Maximum control | ModSecurity plus OWASP CRS |
| Compliance documentation | Enterprise appliance (F5, Imperva) |
| Cloud-native embedding | Coraza |
| Lowest cost | Open-source engine on existing infrastructure |
Mistakes That Show Up Again and Again
Running in blocking mode without a tuning period. Every WAF example above will produce false positives on a real application. Log first, block later.
Treating the WAF as a substitute for secure code. A WAF is a compensating control. The OWASP Top 10 exists because the underlying vulnerabilities keep appearing in code, and no ruleset fixes a broken authorization check.
Ignoring the compliance angle. PCI DSS v4.0 permits a WAF in front of public-facing web applications as an alternative to code review, but only if it’s actively blocking and regularly reviewed. A WAF in detection-only mode doesn’t satisfy that requirement, and assessors check.
Forgetting about APIs. Most WAF tuning guides focus on HTML forms. If your traffic is JSON over POST, you need to verify that your ruleset actually parses and inspects those bodies, because many default configurations don’t.
Never reviewing the logs. A WAF that blocks attacks nobody reads about is a compliance artifact, not a security control. Someone needs to look at what’s being blocked and what’s getting through.
A Note on Testing Your Setup
Before trusting any WAF, test it. Send known-malicious payloads at a staging environment and confirm they’re blocked. Then send your own application’s legitimate traffic and confirm it isn’t. Both directions matter, and the second one is the one teams skip.
For teams that enjoy hands-on projects, the same discipline of testing before trusting applies to other technical builds, whether that’s a home climbing wall DIY project with seven simple steps or a Pokémon FireRed cheats emulator setup. Verify the configuration works before you rely on it. Security is no different.
Conclusion
The web application firewall examples above span a huge range, from a free open-source engine you configure by hand to a managed edge service you enable in an afternoon. None of them is universally best. ModSecurity plus the OWASP CRS gives maximum control at the cost of maintenance. AWS WAF and Cloudflare WAF trade control for speed and low operational burden. F5 and Imperva suit enterprises with stable applications and compliance obligations. Coraza fits modern containerized stacks.
What separates a working deployment from a failed one is rarely the product. It’s whether the team ran in detection mode first, tuned out false positives, kept the ruleset updated, and actually read the logs. Pick the example that matches your operational capacity, then do the boring work.
Frequently Asked Questions
What is a web application firewall example in simple terms?
A simple example is Cloudflare WAF in front of a WordPress site. Traffic hits Cloudflare’s edge first, managed rules check each request for SQL injection or cross-site scripting patterns, and anything that matches a block rule never reaches the server. No code changes, no server configuration, just a DNS change and a toggle.
Is ModSecurity still a good choice?
Yes, for teams that want control and can maintain it. ModSecurity remains the most widely deployed open-source WAF engine, and the OWASP Core Rule Set is actively maintained. The caveat is operational: you own the tuning, the updates, and the false-positive triage. If nobody on the team can do that work, a managed service is a better fit.
Do I need a WAF if my application is already secure?
It’s a reasonable question, and the honest answer is that a WAF is a compensating control, not a replacement for secure code. Even well-built applications face credential stuffing, scraping, and zero-day probing in dependencies. A WAF reduces noise and blocks commodity attacks, which buys your team time to fix real vulnerabilities.
How long does WAF tuning usually take?
For a typical business application, plan on one to two weeks of detection-only mode before enabling blocking, then ongoing monthly review. Complex applications with rich text editors, file uploads, or unusual API payloads can take considerably longer. Teams that skip this phase almost always end up disabling the WAF after an outage.
What is the difference between a WAF and a network firewall?
A network firewall filters by IP address, port, and protocol. A WAF inspects the content of HTTP requests, looking at headers, parameters, and bodies for attack patterns. NIST classifies them separately for exactly this reason. Most production architectures use both, since they cover different layers.
Can a WAF block bot traffic without blocking Google?
Yes, but it requires care. Reputable crawlers publish IP ranges you can allowlist, and most managed WAFs include verified-bot lists. The risk is over-blocking: aggressive bot rules frequently catch monitoring tools, uptime checkers, and payment provider callbacks. Test with real third-party integrations before enabling strict bot management.
