What is a web application firewall (WAF)?
A web application firewall (WAF) is a security layer that sits between your website and the internet, inspecting every HTTP and HTTPS request and blocking the ones that look malicious before they reach your application. Unlike a traditional network firewall, which filters traffic by IP address and port, a WAF understands web traffic itself, so it can spot and stop attacks like SQL injection, cross-site scripting, malicious file uploads, brute force logins, and abusive bots.
A WAF is one of the most effective layers you can add to a website, especially one built on a popular CMS with many third-party plugins. This article explains how a WAF works, the different types available, what it can and can't protect against, and how to choose and configure one for your site.
How Is a WAF Different from a Network Firewall?
Traditional firewalls work at the network and transport layers. They decide whether to allow a connection based on the source IP, destination port, and protocol. For example, a server firewall like UFW might allow ports 80 and 443 and block everything else.
That's useful, but once port 443 is open, a network firewall has no idea whether the request coming through is a normal page view or an attempt to exploit a plugin. A WAF works at the application layer (layer 7). It looks inside the request, including the URL, query string, headers, cookies, and body, and judges whether the content is safe.
| Feature | Network Firewall | Web Application Firewall |
|---|---|---|
| Layer | Network/transport (L3–L4) | Application (L7) |
| Filters on | IP, port, protocol | URLs, parameters, headers, body |
| Stops SQL injection | No | Yes (known patterns) |
| Stops port scanning | Yes | No |
| Typical examples | UFW, iptables, nftables | Cloudflare WAF, Wordfence |
You typically want both: a network firewall to close unused ports and a WAF to protect the ports you must keep open.
How Does a WAF Work?
When a request arrives, the WAF evaluates it against a set of rules and decides whether to allow, block, challenge, or log it.
-
Request inspection: The WAF parses the incoming request, decoding URLs and form data so obfuscated payloads are normalized.
-
Rule matching: It compares the request against rules. Some look for known attack patterns, such as SQL keywords in unexpected places or
<script>tags in parameters. Others check reputation data, request rates, or behaviour. -
Scoring or decision: Some WAFs block on the first matching rule. Others use anomaly scoring, adding points for each suspicious trait and blocking only once the score crosses a threshold, which reduces false positives.
-
Action: The request is allowed through, blocked with an error page (often a 403), presented with a challenge such as a CAPTCHA or JavaScript check, or logged for review.
-
Logging and reporting: Blocked and flagged requests are recorded so you can see what's being stopped and tune the rules.
Blocklist vs. Allowlist Approaches
WAFs generally operate using one or both models:
- Negative security model (blocklist): Block requests that match known bad patterns. Easy to deploy and good for general-purpose sites.
- Positive security model (allowlist): Allow only requests that match expected patterns and block everything else. Very strong but requires careful tuning, so it's more common for APIs and custom applications.
Virtual Patching
One of the most valuable WAF features is virtual patching. When a vulnerability is disclosed in a popular plugin, WAF vendors can push a rule that blocks attempts to exploit it. This protects you during the window between disclosure and the moment you install the official update. It doesn't replace updating, but it buys you time.
Types of Web Application Firewalls
WAFs come in three main deployment models.
Cloud-Based (DNS-Level) WAFs
A cloud WAF runs on the provider's network. You point your domain's DNS at the provider, and all traffic passes through their edge servers before reaching your host.
Examples: Cloudflare, Sucuri Firewall, Akamai, AWS WAF (with CloudFront), Fastly.
Advantages:
- Blocks attacks before they touch your server, saving resources.
- Often includes a CDN and DDoS protection.
- No software to install on your server.
Considerations:
- Attackers who discover your origin server's real IP can bypass the WAF, so you should restrict origin access to the provider's IP ranges.
- Some advanced rules require paid plans.
Application-Level (Plugin) WAFs
An application-level WAF runs inside your website software. On WordPress, security plugins provide this.
Examples: Wordfence, Solid Security, BBQ Firewall, NinjaFirewall.
Advantages:
- Understands the application context, such as which user is logged in.
- Easy to install from Plugins > Add New Plugin.
- Can't be bypassed by hitting the origin IP directly.
Considerations:
- Uses your server's resources, since requests reach PHP before being blocked.
- Can't stop large volumetric attacks.
Wordfence, for example, offers an "Extended Protection" mode that loads the firewall before WordPress itself using PHP's auto_prepend_file setting, so it inspects requests earlier.
Server-Level (Host-Based) WAFs
These run in the web server software on your host, inspecting requests before they reach your application.
Examples: ModSecurity (with the OWASP Core Rule Set), Coraza, Imunify360, and WAFs built into many managed hosting platforms.
Advantages:
- Protects every site and application on the server.
- Faster than a PHP-based plugin WAF.
Considerations:
- Requires server access and expertise to configure and tune.
- Often managed by your host rather than by you.
What Can a WAF Protect Against?
A well-configured WAF can block or reduce:
- SQL injection attempts using known patterns.
- Cross-site scripting (XSS) payloads in parameters and forms.
- Local and remote file inclusion attempts such as
../../etc/passwd. - Exploits for known plugin and theme vulnerabilities via virtual patching.
- Brute force and credential stuffing through rate limiting and challenges.
- Malicious bots and scrapers using reputation and behavioural signals.
- Application-layer DDoS floods of expensive requests.
- Malicious file uploads such as PHP web shells disguised as images.
What a WAF Can't Do
A WAF is powerful, but it has limits:
- It doesn't fix vulnerable code: It blocks known exploit patterns, but novel attacks or logic flaws may slip through.
- It can't stop stolen passwords used normally: If an attacker logs in with valid credentials, the traffic looks legitimate. Two-factor authentication handles this.
- It won't catch everything in encrypted or unusual formats unless configured to inspect them.
- It doesn't replace updates, backups, or monitoring.
- It can cause false positives, blocking legitimate requests like saving a post that contains code snippets.
Think of the WAF as a strong outer wall, not the whole castle.
How to Choose a WAF for Your Website
Ask yourself a few questions:
- What does your host already provide? Many managed WordPress hosts include a server-level WAF. Check before adding more.
- Do you need DDoS protection and a CDN? If so, a cloud WAF like Cloudflare gives you all three.
- How much control do you want? Plugin WAFs are easiest to manage from your dashboard. Server WAFs offer the most power but need expertise.
- What's your budget? Free tiers exist for Cloudflare and Wordfence; advanced rules, faster rule updates, and support usually cost extra. Prices vary widely by provider and plan.
For many small and medium sites, a combination works best: a cloud WAF at the edge plus a plugin WAF inside the application.
Configuring a WAF: Practical Tips
Lock Down Your Origin Server
If you use a cloud WAF, make sure attackers can't simply bypass it by connecting to your server's IP directly. On Nginx, you can restrict access to the provider's IP ranges. The ranges below are placeholders; always use the current list published by your provider:
# /etc/nginx/snippets/cdn-only.conf
# Replace these with your WAF provider's current published IP ranges.
allow 203.0.113.0/24;
allow 198.51.100.0/24;
deny all;
Then include it in your server block with include snippets/cdn-only.conf;. Test carefully, because a mistake here will make your site unreachable.
Start in Learning or Log-Only Mode
Most WAFs let you run in a monitoring mode first. Wordfence has a "Learning Mode," and ModSecurity can run with SecRuleEngine DetectionOnly. Run in this mode for a week or so to identify false positives before switching to blocking.
A basic ModSecurity toggle looks like this:
# Log matches without blocking while you tune rules
SecRuleEngine DetectionOnly
# Switch to blocking once you're confident
# SecRuleEngine On
Allowlist Carefully
If legitimate actions are blocked, such as a page builder saving layouts or an admin pasting code, allowlist the specific rule and URL rather than disabling the firewall. Keep allowlists narrow.
Protect High-Risk Endpoints
Add stricter rules or rate limits for login pages, XML-RPC, password reset, checkout, and search. With Cloudflare, for instance, you can create a rate limiting rule for requests to /wp-login.php from Security > WAF > Rate limiting rules. Menu names in these dashboards change over time, so check the provider's current documentation.
Review Logs Regularly
WAF logs show what's hitting your site. A sudden spike in blocked requests against a particular plugin path may indicate a new vulnerability being exploited in the wild, which is a cue to check for updates.
Does Every Website Need a WAF?
Not strictly, but most benefit. A static site with no forms or server-side code has little for a WAF to protect. A WordPress site with plugins, logins, comments, and forms is exactly the kind of target a WAF is designed for. Given that good free options exist, adding one is usually a sensible, low-cost decision.
FAQ: Web Application Firewalls
A WAF inspects every request sent to your website and blocks the ones that look like attacks, such as attempts to inject code, exploit plugins, or guess passwords, before they can reach your site.
Cloudflare offers a WAF as part of its platform, along with a CDN and DDoS protection. Its free plan includes some managed protections, and paid plans unlock more advanced rule sets and controls.
Many security plugins, like Wordfence, include an application-level WAF. You may also benefit from a cloud WAF at the edge, which blocks traffic before it uses your server's resources.
A cloud WAF with a CDN often makes a site faster through caching. Plugin-based WAFs add a small amount of processing to each request, which is usually negligible on decent hosting.
A false positive is when the WAF blocks a legitimate request because it resembles an attack, such as saving a post that contains code. You fix it by allowlisting the specific rule for that specific action.
Sometimes. Attackers may find new payloads that rules don't recognize, or bypass a cloud WAF by connecting directly to your origin IP. Restricting origin access and keeping software updated reduce this risk.
No. A WAF blocks malicious requests coming in, while a malware scanner checks your files and database for infections that already exist. Both are useful and complement each other.
Conclusion
A web application firewall inspects HTTP traffic at the application layer and blocks malicious requests such as SQL injection, XSS, file inclusion, exploit attempts against known plugin vulnerabilities, and abusive bots. It comes in cloud, plugin, and server-level forms, each with its own strengths, and many sites benefit from combining an edge WAF with an application-level one.
Remember that a WAF is a layer, not a cure-all. It buys you time through virtual patching and filters out a huge amount of automated noise, but it works best alongside regular updates, strong authentication, backups, and monitoring. Start in log-only mode, tune out false positives, lock down your origin, and review your logs, and your WAF will quietly stop a large share of attacks before you ever notice them.
