You may have seen advice like “just install a WAF and you are fine.” But a WAF (Web Application Firewall) and rate limiting are filters that sit in front of your site. They do not repair the weakness inside it. This article explains what each one does, what it is good and bad at, and what is easy to miss after you turn it on. We then place both in the right role for vulnerabilities: a way to buy time until you can update. Features differ greatly by product and contract, so this stays at the level of general principles.
What a WAF is: a reception desk in front of the site
A WAF inspects the contents of each incoming request and decides whether to let it through or stop it. Think of a reception desk at the entrance of your site.
It can live in several places:
- Cloud-based (in front of a CDN or similar): filters requests before they reach your site, running on the provider’s network
- Server-side feature: some hosting providers offer one. Whether it is on depends on your plan and control panel settings
- Plugin-based: runs inside WordPress. Because it decides after PHP has started, it sits further inside than the two above
Where it sits changes what it can see and what it can stop. It is worth finding out which one, if any, is running on your site.
What rate limiting is: drawing a line by count
Rate limiting looks at how often, not what. It decides based on how many requests one source has made in a given time.
Typical uses are repeated attempts against the login page (wp-login.php) and bursts of traffic meant to overload a site. Even if each password attempt looks legitimate, an unnatural count can be stopped.
A WAF (what is in the request) and rate limiting (how many requests) are different viewpoints. Some products bundle both.
What they are good at
- Blocking clearly suspicious requests that match well-known patterns: familiar shapes of request can be stopped at the desk
- Slowing repeated login attempts: a count-based line reduces the payoff of mechanical guessing
- Reducing noise in access logs: if routine probing stops at the entrance, logs become easier to read. See how to read WordPress access logs
- Sometimes creating a grace period: right after a vulnerability is disclosed, a provider may ship a rule that blocks its abuse (often called “virtual patching”). Whether a rule exists and when it arrives varies by product and vulnerability, and none of it is guaranteed
What they are weak at
Filtering at the entrance has trouble with the following:
- Requests that look legitimate: a well-formed request that appears to be an authorized action may be indistinguishable by content alone. Weaknesses in the site’s own design fall in this group
- Real logins with stolen credentials: with a genuine username and password, the person looks like an ordinary user
- Updates from a compromised distribution source: things that arrive through a channel you trust are rarely suspected. This is one of the types covered in our supply chain article
- Anything already placed inside the site: entrance protection does not act on what happened after entry. If you suspect that, follow the order in the first-response article
- Paths that bypass the WAF: with a cloud WAF, an open direct path to the origin server may let requests skip the desk. Check that “the WAF is in front” is actually true of your setup
Common stumbling blocks after turning it on
The stronger the protection, the more likely it is to stop legitimate users too.
- False positives: saving in the editor, REST API calls, image uploads, and notifications from payment or external services can be flagged. A sudden site malfunction turning out to be the WAF is not unusual
- Collateral stops on shared sources: traffic from one office or facility network can look like a single source from outside. A strict rate limit may stop several legitimate users together
- Misjudged client address: behind a CDN or proxy, the address your site sees may be the relay, not the actual visitor. If the count is attached to the wrong address, the limit may not work or may hit everyone at once. It needs settings that match your architecture
- Starting in “log only” mode: many products can record without blocking. Looking at what gets flagged before enforcing makes false positives easier to notice
How to check that it behaves as intended
After configuring, confirm it works as expected. These are read-only checks:
- In the access logs, watch the number of stopped responses (such as 403 or 429) before and after the change. HTTP status meanings are covered in our HTTP status codes article
- Try normal admin work: saving a post, uploading an image, changing a plugin setting
- Make sure blocked requests are recorded, so you can review them later
Testing your own site with attack-like traffic can violate your provider’s terms or affect other customers. Staying within logs and ordinary operations is the safer course.
The relationship to updates: time bought, not a substitute
A WAF and rate limiting do not remove the weakness. As long as it remains, requests that slip past the desk may still work. There are periods when rules lag behind, and weaknesses that no rule covers.
So the roles can be summarized like this:
- Updates (patches): remove the weakness. This is the thing to do
- WAF and rate limiting: an additional layer that may reduce harm in the meantime
For thinking about update timing, see our article on time to exploitation; for trimming unused plugins, see the plugin inventory article. Adding layers and keeping up with updates go together.
Limits and things to keep in mind
- Features, rule content, and update frequency differ widely by provider and contract. Having one installed is different from your site being protected
- Weaknesses that rules do not cover, and cases where legitimate traffic is stopped, never fully disappear
- A small number of blocked requests does not prove that no attacks are arriving
Summary
- A WAF looks at content and rate limiting looks at count, deciding in front of the site what to pass and what to stop
- They help with known suspicious requests and repeated login attempts, but are weak against legitimate-looking requests, stolen credentials, compromised distribution sources, and anything already inside
- After enabling, watch for false positives and misjudged client addresses, and consider starting in log-only mode
- The role is an additional layer that can buy time until you update. It is not a replacement for updating
No single layer stands alone. Think of protection as combining updates, inventory, permissions, and backups.