Someone has told you your website needs a firewall. Maybe it was your host, maybe a security plugin nagging in the dashboard, maybe a developer who said “just put it behind Cloudflare.” You nodded, but it is not obvious what a website firewall actually does, whether you already have one, or whether turning it on could break something.
This is a plain explanation of what a web application firewall (WAF) is, the two main kinds, what each one stops and misses, and how to set one up without locking out your own customers.
A WAF is not the same as a server firewall
Most hosting servers already have a network firewall. It works at the level of ports and connections: it decides which kinds of traffic may reach the server at all, such as allowing web traffic and blocking someone trying to connect to a database port from outside. It does not read the content of a web request.
A web application firewall works one level up. It looks inside each web request, at the address being requested, the form data being sent and the headers, and compares it against rules. A request that tries to slip database commands into a search box, or that matches a known exploit for a popular plugin, can be blocked even though it arrives on the normal web port like every genuine visitor.
So the two are not alternatives. A network firewall keeps the wrong doors shut. A WAF checks what people are carrying through the door that has to stay open.
The two kinds of WAF
Cloud or DNS-level WAF
Services such as Cloudflare and Sucuri sit in front of your website. You change your domain’s DNS so that visitors reach their network first, and they pass clean traffic on to your server. Bad requests are filtered before they ever touch your hosting.
The big advantage is that your server does less work. Floods of bot traffic, login guessing and junk requests are absorbed elsewhere, which matters on modest shared hosting. These services usually also cache pages, which can make the site faster.
The trade-offs are real, though. You are routing all your traffic through a third party, so DNS has to be set up carefully, and a mistake can take the site or your email offline. And if an attacker discovers your server’s real IP address, they can go around the WAF entirely unless the server is set to accept web traffic only from the WAF’s network.
Plugin or application-level WAF
Wordfence is the best-known example. Its firewall runs on your own server, as part of WordPress or just before WordPress loads. It can see things a cloud service cannot, such as which user is logged in and which plugins are installed, so its rules can be quite specific to WordPress.
The trade-off is that every request still reaches your server. The plugin blocks the attack, but your hosting has already done the work of receiving it and starting PHP. During a heavy flood, that can still slow the site down. A plugin firewall also cannot protect you if the problem is below WordPress, for example a compromised hosting account.
| Cloud / DNS-level | Plugin / application-level | |
|---|---|---|
| Where it filters | Before traffic reaches your server | On your server, inside or just before WordPress |
| Server load during attacks | Mostly taken off your server | Your server still receives every request |
| Knowledge of WordPress | General rules plus WordPress rule sets | Sees users, plugins and settings directly |
| Setup risk | DNS changes; origin IP must be protected | Plugin conflicts; can lock you out of admin |
Many sites use both: a cloud WAF to take the volume off the server, and a security plugin for login protection, file scanning and WordPress-specific checks.
What a WAF does stop
- Known exploit patterns. Common attack shapes such as SQL injection and cross-site scripting, and exploits for vulnerabilities that have already been published, provided the WAF has a rule for them.
- Bad bots and scanners. Automated tools that crawl sites looking for weak spots, old files and exposed admin pages.
- Brute-force login attempts. Rate limits and blocks on repeated login failures. Our guide to stopping WordPress brute-force attacks covers the settings that work alongside this.
- Some denial-of-service traffic. A cloud WAF can absorb or challenge floods of requests. A plugin WAF helps far less here, because the traffic still lands on your server.
What a WAF does not stop
This is the part that gets oversold. A WAF is a filter, not a cure.
- Weak or stolen passwords. If someone logs in with a real username and the right password, that looks like a normal visitor. Two-factor authentication is what protects you here.
- Outdated plugins it has no rule for. A WAF blocks attacks it recognises. A flaw that is new, or in a small plugin nobody writes rules for, may go straight through. Keeping plugins updated, and replacing ones that are no longer maintained, still matters. See what to do about an abandoned plugin.
- A site that is already infected. Putting a WAF in front of a hacked site does not remove the malware or the backdoor the attacker left. Clean the site first; this step-by-step guide to fixing a hacked WordPress site explains how.
- Mistakes inside the site. An administrator installing a bad plugin, or a staff member sharing a login, is not something a firewall can see.
False positives: when the firewall blocks the wrong people
Every WAF blocks some legitimate traffic sooner or later. The common symptoms:
- A customer says the contact form “doesn’t send” or shows an error page, often because their message contained something the rules thought looked like code.
- Visitors from certain countries or networks see a challenge page, or are blocked outright, after someone turned on country blocking.
- You save a page in the editor and get a “forbidden” error, because the content looked suspicious to a rule.
- Orders are paid but stay “pending” in WooCommerce.
That last one deserves attention. Payment gateways confirm payments by sending a request from their own servers back to your site, often called a webhook or callback. No human is involved, so a WAF set to challenge bots can block it. The customer has paid, but your store never hears about it. If you take payments online, find your gateway’s webhook address and make sure the WAF allows it.
Setting one up without breaking the site
- Take a full backup first. Files and database, stored somewhere other than the server.
- For a cloud WAF, write down your current DNS records before changing anything, especially the mail records. Email breaking after a DNS move is common and easy to avoid.
- Start in a learning or monitoring mode if one is offered. Wordfence, for example, has a learning mode so the firewall can see normal traffic before it starts blocking.
- Allow the traffic you depend on: payment gateway callbacks, any booking or shipping service that sends data to your site, and your own office IP if you want to avoid being challenged.
- Test the things that make money. Submit the contact form, place a test order, log in as a customer, check that order confirmation emails arrive.
- Protect the origin. With a cloud WAF, ask your host to accept web traffic only from the WAF provider’s network, so attackers cannot bypass it.
- Read the block log for the first couple of weeks. It tells you both what the WAF is catching and who it is wrongly stopping.
Avoid stacking two plugin firewalls on the same site. They tend to conflict, and when something breaks it becomes very hard to tell which one caused it.
Do you need one?
For most business websites a WAF is worth having, and both Cloudflare and Wordfence offer free versions to start with. But it sits on top of the basics, not in place of them: updated software, strong passwords with two-factor login, tested backups and someone actually reading the alerts.
If you would like someone to set up and watch a firewall alongside those basics, that is part of our website security maintenance work. We can check what your site currently has and tell you what is missing before you decide anything.
Next in this series: Protecting wp-config.php: Practical WordPress Hardening
