What Your Hosting Provider Should Handle for WordPress Security

The security plugin is standing in the wrong place

When a WordPress site gets hacked, everyone blames the owner. Should have updated the plugins. Should have used a stronger password. Should have installed a security plugin, or a second one, or a third.

Sometimes that’s fair. But there is a whole layer of WordPress security that cannot be done from inside wp-admin, no matter how diligent you are and no matter how many plugins you stack. It happens on the server, below your login, in places only your hosting provider can reach, and plenty of providers quietly don’t bother.

This article maps that gap. It isn’t another hardening checklist so much as a division of labor: what your host should be handling without being asked, what genuinely stays your job, and the questions that reveal which kind of host you actually have.

Security splits at the server line

A WordPress site is an application running on somebody else’s computer. Most of the model follows from that sentence.

Everything below the application belongs to whoever runs the server: the network it sits on, the operating system, the web server, the PHP runtime, and the other tenants sharing the machine. Everything inside the application is yours: your users, your passwords, your theme, and every plugin you chose to install.

Cloud providers call this the shared responsibility model and print tidy diagrams about it. Hosting companies mostly don’t bring it up, which is convenient, because ambiguity about whose job something is means nobody notices when it isn’t done.

Six things your host should be doing without being asked

1. Absorbing DDoS attacks before they reach you

A volumetric attack is junk traffic at a scale designed to saturate whatever it hits. Nothing inside WordPress can help you here. By the time a malicious request reaches your site, the server has already spent resources on it; multiply that by a few million requests a minute and the site is down regardless of what any plugin does. DDoS mitigation only works at the network edge, filtering the flood before it touches your server, and only your host can put it there.

The question to ask: is DDoS protection automatic and included, or an add-on you’re expected to discover after your first attack?

2. Filtering exploits before they execute

A web application firewall inspects incoming requests and blocks known exploit patterns, such as SQL injection attempts or calls to a vulnerable plugin endpoint, before they run. What matters is where it stands. A WAF at the server level evaluates the request before WordPress even loads. A “firewall” plugin runs inside WordPress: it boots after core boots, sees the request only after the application has already started handling it, and gets disabled along with everything else when the site is compromised. It’s a fine extra layer and a poor only layer.

Ask whether the WAF runs at the server level, and who maintains its rules.

3. Keeping the neighbors out of your account

On shared infrastructure, your site lives on a machine with many others. Without enforced isolation, one compromised account becomes a foothold for reading other tenants’ files or burning the CPU everyone shares. Proper isolation, the kind CloudLinux provides, walls each account into its own contained environment with its own resource limits, so a stranger’s abandoned plugin stays a stranger’s problem.

So ask exactly that: if another account on my server is compromised, what stops it from reaching mine? Then watch how long a straight answer takes. This one separates hosts that run a hardened platform from resellers who run a landing page.

4. Scanning for malware from outside the blast radius

Malware’s first job is to hide. A scanner installed as a plugin lives inside the environment it’s supposed to police, and malware with the same privileges can blindfold or simply deactivate it. Server-side scanning inspects the filesystem from outside the application, which is the vantage point malware can’t switch off, and a serious setup quarantines what it finds and alerts someone automatically instead of waiting for you to run a scan by hand.

Ask where scanning runs, how often, and what happens when something turns up.

5. Encrypting by default

TLS is boring right up until a certificate expires and every visitor meets a browser warning instead of your site. Certificates should be free, installed automatically, and renewed automatically, on every domain, without a ticket. In 2026, a host charging extra for basic SSL is charging for tap water.

You don’t need to ask about this one, because the order form will tell you.

6. Patching everything you can’t see

Kernel vulnerabilities, PHP versions aging out of security support, web server CVEs: none of it is visible from wp-admin, and all of it is your attack surface. Your host’s patching cadence is your exposure window. Managed WordPress hosting extends this one rung higher into your territory, applying core updates automatically so that the window between a disclosed vulnerability and your patched site is measured in hours rather than in however long it takes you to notice.

Two things to ask here: who patches PHP and how quickly after a CVE, and do you still run versions that are past end-of-life? The second one is a trap, and it’s supposed to be. PHP 7.4 stopped receiving security fixes at the end of 2022; a host still offering it as a default in 2026 has answered every other question too.

What stays on your side of the line

Now the honest half. There are things no host can take off your plate, and a provider that claims otherwise is overselling.

Credentials come first. Most WordPress compromises don’t exploit anything; they log in. A weak password, a reused one that surfaced in someone else’s breach, an admin account nobody remembers creating. Strong unique passwords, two-factor authentication, as few administrators as possible, and access removed the day someone leaves. Nobody can do this for you.

The plugin diet is yours too. Every plugin is third-party code you chose to run with full access to your site, so run fewer of them, pick ones that are actively maintained, and update promptly. Managed hosting narrows the update window; choosing what to install is forever yours. What happens to sites that skip this part, now that attackers use AI to work through published vulnerabilities, is in our post on outdated WordPress and Joomla software.

Email authentication also sits on your side, because SPF, DKIM, and DMARC are DNS records only you control. Unauthenticated email is a deliverability problem and a security one at the same time, since it’s what lets attackers spoof your domain. We wrote a full cPanel walkthrough for setting up all three.

And backups. A good host gives you automated backups and a self-serve restore, but confirming they actually restore is a ten-minute job that belongs to you. We’ve made the case for never skipping it.

For the step-by-step version of the application-layer work, our knowledge base has a practical guide: Securing WordPress.

The five questions, in one place

Copy these into a pre-sales chat with any host you’re evaluating, including us:

1. Is DDoS protection automatic and included on every plan?
2. Is there a server-level web application firewall, and who maintains its rules?
3. If a neighboring account on my server is hacked, what isolates mine?
4. Does malware scanning run server-side, and what happens when it finds something?
5. Who patches PHP, and what’s your policy on end-of-life versions?

A host that handles its half of the model can answer all five in one reply. One that doesn’t will usually just recommend a security plugin.

Where GOZEN HOST draws the line

We’d be hypocrites to hand you interrogation questions and dodge them ourselves, so these are ours.

On our cPanel platform, which runs both the shared and WordPress plans, every account gets CloudLinux isolation with its own resource limits, a ModSecurity web application firewall at the LiteSpeed server level, and cPGuard, a server-side security suite that scans for malware daily, quarantines what it finds, and alerts on detection. DDoS filtering is always on and starts automatically on every plan. SSL certificates install and renew themselves on every domain. Daily offsite backups come with a restore you can run yourself. The managed WordPress plans add automatic core updates and one-click staging, so updates get tested somewhere disposable instead of on your live site. The full stack is laid out on our security page.

And the honest caveat, straight from our own knowledge base: application-level security is up to you. We can’t choose your plugins, guard your passwords, or fire your former contractor’s admin account. What we can do is make sure that when you do your half, nobody has quietly skipped the other half underneath it.

The short version

WordPress security splits at the server. When your host handles their half, you inherit DDoS protection, a real WAF, account isolation, server-side scanning, and a patched stack on day one, invisibly. When they don’t, no plugin fills the hole, because the hole is under the floor the plugin is standing on.

If you’re currently assembling firewalls and scanners out of plugin subscriptions, you’re doing your host’s job and paying twice for it. See what’s already included with our WordPress hosting, and if it’s not what your current host includes, moving is free and we handle the migration.