What a WAF does
A web application firewall — WAF for short — sits between the internet and your website. Every request that comes in passes through it first. The WAF inspects that traffic, decides whether it looks legitimate, and either lets it through or blocks it.
Think of it like a security checkpoint at the entrance to a building. A lock on your office door is good to have. But a guard in the lobby who stops suspicious people before they get to your floor? That’s a different level of protection. The WAF is the guard in the lobby.
The one we deployed is open-source, well-maintained, and built on industry-standard rule sets that are continuously updated to match the latest known threats. It’s not experimental. It’s proven infrastructure used in production environments around the world.
Why this runs at the infrastructure level, not inside WordPress
Most WordPress security solutions are plugins. Wordfence, Sucuri, iThemes — they all work the same way. They install inside WordPress and use your site’s own resources to inspect incoming traffic.
That means every request — legitimate or malicious — has to load WordPress, load PHP, load the plugin, and then decide whether the visitor is a threat. Your site does the work of processing an attack before it can block it. During a brute-force attempt or a bot swarm, that’s hundreds or thousands of extra requests your server has to handle. Your site slows down while it’s busy defending itself.
Our WAF works differently. It runs at the infrastructure level, in front of WordPress entirely. Malicious traffic gets dropped before it touches your site. WordPress never sees it. Your server never processes it. There’s zero performance cost to your site — no extra CPU, no extra memory, no extra load time.
There’s another advantage: it can’t be bypassed by a compromised plugin or a WordPress vulnerability. If an attacker exploits a flaw in a plugin to disable security features, a plugin-based WAF goes down with it. An infrastructure-level WAF doesn’t care what happens inside WordPress — it’s a separate system, running independently.
And because it’s centralized, we manage the rules and updates once, and the protection applies to every site on our platform simultaneously. No waiting for individual site owners to update a plugin. No inconsistencies between sites.
What it protects against
Without getting into specifics that would help the wrong people, here’s the general picture:
- Common web application attacks. SQL injection, cross-site scripting (XSS), and the other vulnerabilities on the OWASP Top 10 — the industry-standard list of the most critical security risks for web applications. These are blocked by default using well-established rule sets.
- Brute-force login attempts. WordPress login pages are constantly targeted by bots trying username/password combinations. The WAF applies rate limiting and blocks repeat offenders at the network edge, before they can hammer your login page.
- Malicious bots. Not all bots are bad — search engine crawlers are bots, and you want those. But a lot of bot traffic is scrapers, spammers, and vulnerability scanners probing your site for weaknesses. The WAF identifies and blocks the bad ones.
- DDoS mitigation. A distributed denial-of-service attack floods your server with so much traffic that it can’t respond to real visitors. A plugin can’t stop this because by the time the plugin runs, the server is already overwhelmed. The WAF handles connection limiting and traffic shaping before requests hit your server.
- HTTP security headers. Things like HSTS and content security policies that tell browsers how to handle your site securely. These are now applied automatically and consistently.
None of this requires you to configure anything, install anything, or even think about it.
Why we’re telling you this
We could have just rolled this out and said nothing. You’d never notice the difference — which is the point. Good security is invisible. You only notice it when it fails.
But we think it’s worth being transparent about what we do and why. This is what we mean when we say our hosting is proactive, not reactive. It’s not just a server you rent. It’s infrastructure that someone is actively improving, hardening, and watching.
Most hosting companies would make this a premium add-on. “Advanced security — $10/month extra.” We’re not doing that. Every site on our platform gets the same protection because every site on our platform deserves it. It’s part of the job.
This is also how we think about the relationship with our clients. We don’t wait for you to ask “is my site secure?” and then offer to sell you a solution. We assume you expect your site to be secure — and we make sure it is.
One less thing to worry about
If you’re an Awwwsome hosting client, there’s nothing you need to do. The WAF is already running, already protecting your site, and already included in your plan.
A note for our Agency Partners on dedicated servers: the WAF isn’t active on your infrastructure yet. Dedicated environments need a slightly different configuration, and we want to get it right rather than rush it. We’re finalizing the rollout now and expect full coverage within the next seven days. You’ll hear from us directly when it’s live.
If you had a WordPress security plugin installed before, it’s not necessarily redundant — defense in depth is a real thing, and layers of protection are generally better than one. But you might find that you no longer need the heaviest (and most resource-hungry) security plugin in your stack. If you want to talk through what makes sense for your site specifically, just reach out.
The whole point of managed hosting is that you shouldn’t have to become a security expert to keep your website safe. That’s our job. This is us doing it.