A Hardening Checklist for Any Web Host
Defense in depth: the layers between an attacker and your data
Your host secures the infrastructure; this checklist secures the half that's yours, and it works on any host. Think of a hosted site as layers of defence — the network edge, the server, the transport (HTTPS), the application, access, and your data — where an attacker has to get through every layer, and the weakest one is usually the one you own. The diagram above maps them. Work down this list once when a site goes live, revisit it a couple of times a year, and you'll have closed the doors most break-ins actually use.
1. Put the site behind Cloudflare's free plan
Start at the edge. Routing your domain through Cloudflare's free plan adds unmetered DDoS mitigation and a basic web application firewall in front of your host, and hides your origin server behind Cloudflare's network. It's free, it's fast to set up, and it's the highest-value single upgrade for most sites — we recommend it because it works and earns us nothing. Just keep your origin server's real IP address private so attackers can't bypass the proxy, and set the SSL mode to Full (strict). The details are in DDoS protection in hosting.
2. Force HTTPS everywhere
Confirm your free SSL certificate is active and auto-renewing, then force every visitor onto HTTPS with a site-wide redirect, and fix any mixed content so no page loads insecure resources. This is transport-layer security, and it's mostly a one-time configuration on a good host. Test it by visiting the http:// version and confirming it redirects. The full walkthrough, including the mixed-content fix, is in HTTPS and SSL setup basics.
3. Update everything, and remove what you don't use
This is the application layer, and it prevents the most common kind of compromise. Keep your CMS core, plugins and themes updated — enable automatic updates for security releases where you can — and delete every plugin, theme and old install you're not actively using, because unused code is still attack surface that never gets your attention. Outdated, abandoned extensions are a leading entry point for automated attacks that scan the web for known vulnerabilities. If a plugin hasn't been updated by its author in a long time, treat that as a reason to replace it, not just to leave it running.
4. Use a password manager and unique passwords
Every login — CMS admin, hosting control panel, database, FTP, email — should have a long, random, unique password stored in a password manager. Reused passwords are how a breach at some unrelated service becomes a break-in at yours, via automated credential-stuffing. A password manager makes unique passwords effortless, which is the only way people actually maintain them. This costs nothing and removes an entire category of attack, so it belongs near the top of any honest hardening list.
5. Turn on two-factor authentication
Two-factor authentication (2FA) means a stolen password alone can't get in, and it defeats the brute-force, credential-stuffing and most phishing attacks that rely on passwords. Enable it on your CMS admin and — most importantly — your hosting control panel, which is the master key to your whole account. Use an authenticator app rather than SMS where you have the choice, since app-based codes aren't vulnerable to SIM-swapping. This is the access layer, and 2FA is the highest-leverage control on it.
6. Limit access with least privilege
Give every user the least access they need, and no more. Don't hand out administrator accounts when an editor role will do, remove accounts for people who've left, and audit who has access a couple of times a year. Every admin account is a full set of keys and another target; fewer of them means a smaller attack surface and less damage if one is compromised. The same principle applies to any integrations and API keys — grant narrow permissions and revoke what you no longer use.
7. Scan, and keep your own off-host backups
Finally, the data layer and its safety net. Make sure malware scanning is active — from your host, a reputable security plugin, or both — so an infection is caught early, and understand what your host will and won't clean, as covered in whether you need malware protection from your host. Then keep your own backups off the host, following the 3-2-1 rule, so you can restore a clean copy no matter what happens — an infection, a bad update, or the host itself having a bad day. Test a restore once so you know it works before you ever need it.
Pick a host that does its half
This checklist is your half of the shared-responsibility model, and it works on any host — but it's easier and more effective when the host does its half well, with account isolation, prompt patching, scanning and restorable backups. Start from a host that gets those right, then harden your side on top. Our most secure web hosting ranking scores hosts on exactly the infrastructure controls this checklist assumes underneath it.
Keep a record, and review on a schedule
Hardening isn't a one-time event, so make it maintainable. Keep a short record for each site: what's installed and why, who has access, where the off-host backups live, and when you last tested a restore. It sounds bureaucratic, but it turns security from something you half-remember into something you can actually check. Set a recurring reminder — quarterly is reasonable — to review user accounts, remove unused plugins, confirm backups are running, and run a test restore. Just as importantly, know your recovery steps before you need them: which backup to restore, how to change every credential, and who to contact at your host. The people who recover from an incident in an hour rather than a week are almost always the ones who wrote the plan down while things were calm.
Hardening questions, answered
What's the single most important hardening step?
Do these steps work on shared hosting, or do I need a VPS?
How often should I run through this checklist?
Ready to choose a host? See the most secure web hosting, ranked, or run the web hosting security checklist.