Web Hosting Security Guide 2026: SSL, Backups, Malware & DDoS | Pick Hosting

A client called me last March after their WooCommerce store got hit with a credential-stuffing attack. Their host’s response? “We recommend upgrading to our managed security plan for $49/month.” The site had been compromised for eleven days before anyone noticed. They lost roughly $23,000 in revenue and an unknowable amount of customer trust.

This guide covers the four things that would have prevented that scenario—or at least limited the damage to hours instead of days.

SSL Certificates: The Bare Minimum That Most Hosts Still Get Wrong

Every host in 2026 offers free SSL through Let’s Encrypt. That’s not a feature anymore—it’s table stakes. The real question is how they implement it and what happens when certificates fail to renew.

Auto-Renewal Failures Are More Common Than You Think

Let’s Encrypt certificates expire every 90 days. Most hosts run a cron job to auto-renew them 30 days before expiration. But I’ve seen renewal failures on shared hosting environments at least a dozen times in the past two years, usually caused by:

DNS propagation issues after a domain transfer
The .well-known/acme-challenge directory getting blocked by security plugins or .htaccess rules
Hosts hitting Let’s Encrypt rate limits on shared IP addresses (5 failed validations per hostname per hour)

When auto-renewal fails silently—and it usually does—your visitors see a full-page browser warning. Google Chrome’s interstitial page has a click-through rate of about 3%. That means 97% of your traffic bounces.

What to Actually Do About SSL

Set up monitoring. Use a free service like UptimeRobot or Oh Dear to check your SSL expiration date weekly. Oh Dear sends an alert 30, 14, and 7 days before expiration. This takes five minutes to configure.

Test your SSL configuration. Run your domain through SSL Labs (ssllabs.com/ssltest). You’re looking for an A or A+ rating. Common issues that drop your score:

TLS 1.0 and 1.1 still enabled (your host should have disabled these years ago)
Missing HSTS headers
Weak cipher suites in the server config

Consider paid certificates for specific use cases. If you’re running an e-commerce site processing payments, an Extended Validation (EV) or Organization Validated (OV) certificate from a provider like DigiCert or Sectigo still carries weight with certain enterprise buyers. The cost runs $100-300/year. For most sites, free Let’s Encrypt is fine.

Add HSTS headers. This tells browsers to always use HTTPS, even if someone types http:// or follows an old link. Add this to your server config:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Start with a short max-age (like 300 seconds) and work up. If you mess up HSTS with a long max-age and your SSL breaks, visitors literally cannot access your site over HTTP as a fallback. I’ve seen this lock people out for months.

Many hosts listed in our hosting comparison pages include SSL configuration details—check how each provider handles certificate management before you commit.

Backups: Your Host’s Backup Is Not a Backup Strategy

Here’s the thing most people get wrong about backups: they think having one copy is enough. It’s not. A backup strategy requires multiple copies, in multiple locations, with tested restore procedures.

The 3-2-1 Rule Still Applies

Keep 3 copies of your data, on 2 different types of storage, with 1 copy offsite. For a typical WordPress or CRM-integrated site, that looks like:

Your live server (copy 1)
Your host’s automated daily backup (copy 2, same infrastructure)
An offsite backup to a different provider—S3, Backblaze B2, Google Cloud Storage (copy 3, different infrastructure)

Most shared hosts retain 7-30 days of daily backups. SiteGround keeps 30 daily backups on their GoGeek plan. That sounds great until you realize those backups live on the same infrastructure as your site. If the data center has a catastrophic failure—rare, but it happens—both your site and your backups are gone.

What Your Host Probably Isn’t Telling You About Restores

I test backup restores on every hosting environment I set up for clients. Here’s what I’ve found:

Shared hosting restores typically take 15-60 minutes for sites under 5GB. But on some hosts, you need to open a support ticket and wait for a human. That support ticket takes 2-6 hours during peak times.
Managed WordPress hosts usually offer one-click restores through a dashboard. Kinsta and WP Engine both complete restores in under 10 minutes for most sites.
VPS and dedicated servers often require manual restore from snapshots. If you don’t know how to restore from a DigitalOcean snapshot via the command line, that’s a problem at 2 AM when your site is down.

Building a Real Backup System

For WordPress sites: Use UpdraftPlus (free) or BlogVault ($7.40/month) to send automated backups to a remote storage provider daily. BlogVault is worth the money because it runs backups on its own servers, so it doesn’t slow down your site during the backup process.

For custom applications and CRM integrations: Write a bash script that dumps your database, compresses your files, and uploads to S3. Run it via cron. Here’s the basic structure:

#!/bin/bash
DATE=$(date +%Y-%m-%d)
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > /tmp/db-$DATE.sql.gz
tar -czf /tmp/files-$DATE.tar.gz /var/www/html
aws s3 cp /tmp/db-$DATE.sql.gz s3://your-bucket/backups/
aws s3 cp /tmp/files-$DATE.tar.gz s3://your-bucket/backups/
rm /tmp/db-$DATE.sql.gz /tmp/files-$DATE.tar.gz

Test your restores quarterly. Spin up a staging environment and restore from your latest backup. If you’ve never tested a restore, you don’t have a backup—you have a hope.

Backblaze B2 charges $0.005/GB/month for storage. A 10GB site costs you $0.60/year to back up offsite. There’s no excuse not to do this.

Malware Scanning: Catching Compromises Before Your Customers Do

The average time to detect a website compromise is 287 days according to IBM’s 2025 Cost of a Data Breach report. For small businesses without dedicated security teams, it’s often longer. The WooCommerce client I mentioned at the top went eleven days, and that was actually fast by industry standards.

Server-Side vs. Remote Scanning

There are two types of malware scanning, and you need both.

Remote scanning (tools like Sucuri SiteCheck, VirusTotal) checks what’s publicly visible on your site. It catches defacements, injected spam links, drive-by download scripts, and blacklist entries. But it misses backdoors, hidden PHP shells, and compromised admin accounts because those don’t show up on the front end.

Server-side scanning (tools like Wordfence, ImunifyAV, ClamAV) examines files and databases directly on your server. This catches the stuff remote scanners miss: modified core files, malicious cron jobs, obfuscated PHP in upload directories.

What Good Malware Protection Looks Like

A file integrity monitor compares your CMS core files against known-good checksums. If wp-includes/version.php changes and you didn’t update WordPress, something’s wrong. Wordfence does this automatically.

Daily automated scans of your entire file system. Most managed hosts include this. On SiteGround, their SG Security plugin runs daily malware scans on all plans. Hosts using ImunifyAV (common on cPanel servers) scan in real-time.

Real-time file monitoring catches changes as they happen. This is typically only available on managed hosting or if you install something like OSSEC yourself on a VPS.

Web Application Firewall (WAF) blocks known attack patterns before they reach your application. Cloudflare offers a free WAF with basic rules. Their Pro plan ($20/month) includes the OWASP ModSecurity Core Rule Set, which blocks SQL injection, XSS, and other common attacks.

A Practical Malware Response Plan

Write this down and keep it somewhere accessible. When you get a malware alert:

Don’t panic-delete files. You might break your site worse than the malware did.
Take a snapshot of the current compromised state. You’ll need this for forensics.
Check your access logs for the entry point. Look for POST requests to unexpected endpoints, especially in /wp-content/uploads/ or /tmp/.
Restore from a known-good backup if you have one within the last 24-48 hours.
Change every password. Database, FTP, SSH, CMS admin, hosting panel. All of them.
Update everything. CMS core, plugins, themes. The vulnerability that let attackers in probably still exists.
Request a blacklist review from Google Search Console if you got flagged. This takes 24-72 hours.

If you’re running a CRM integration that stores customer data—HubSpot forms, Salesforce web-to-lead, or something similar—a site compromise potentially exposes that data pipeline. Audit your integration endpoints and API keys after any incident.

DDoS Protection: What Actually Works and What’s Marketing Fluff

A basic volumetric DDoS attack can be purchased for about $30 on various forums. That’s the reality. Your competitor, a disgruntled ex-employee, or a bored teenager can take your site down for the cost of a meal.

Understanding DDoS Attack Types

Volumetric attacks (Layer 3/4) flood your server’s network connection with traffic. We’re talking 10-100+ Gbps of UDP floods, ICMP floods, or amplification attacks. Your shared hosting server’s 1 Gbps port doesn’t stand a chance.

Protocol attacks (Layer 3/4) exploit weaknesses in network protocols. SYN floods, Ping of Death, Smurf attacks. These exhaust server resources rather than bandwidth.

Application-layer attacks (Layer 7) are the sneaky ones. They look like legitimate HTTP requests—hundreds of thousands of them—targeting expensive endpoints. A WordPress site’s xmlrpc.php or /wp-admin/admin-ajax.php processing search queries are common targets. These are harder to distinguish from real traffic.

What Your Host Provides (And What They Don’t)

Most hosts include basic DDoS mitigation at the network level. They’ll filter out obvious volumetric attacks before they reach your server. This handles the low-effort attacks.

What they typically don’t handle:

Application-layer attacks that mimic real user behavior
Sustained attacks lasting more than a few hours (some hosts will actually null-route your IP to protect other customers on the shared server)
Targeted attacks that adapt to your mitigation measures

I’ve seen hosts null-route client IPs during a DDoS attack three times in the past year. They prioritize the other customers on the server over yours. You can’t blame them—one site shouldn’t take down fifty—but it means your “DDoS protection” is actually “we’ll disconnect you to protect everyone else.”

Building Real DDoS Resilience

Put Cloudflare (or a similar reverse proxy) in front of everything. Cloudflare’s free plan includes basic DDoS protection that handles most volumetric and protocol attacks. Their paid plans ($20-200/month) add more sophisticated Layer 7 protection and faster mitigation.

Configure rate limiting. Set up rules to limit requests per IP per minute on sensitive endpoints. Cloudflare’s free plan includes one rate limiting rule. On your server, you can use mod_evasive for Apache or limit_req for Nginx:

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

location /wp-login.php {
    limit_req zone=one;
}

This limits login page requests to 30 per minute per IP. Adjust based on your traffic patterns.

Block xmlrpc.php if you’re not using it. Most WordPress sites don’t need it. This single file is responsible for a massive percentage of application-layer attacks against WordPress:

location = /xmlrpc.php {
    deny all;
    return 444;
}

Have a “DDoS mode” plan ready. Know how to enable Cloudflare’s “Under Attack” mode (adds a JavaScript challenge to every visitor). Know how to temporarily disable resource-heavy features like search, comments, or dynamic page generation. Have a static HTML maintenance page ready to deploy.

Monitor your traffic baselines. If your site normally gets 5,000 requests per hour and suddenly jumps to 500,000, you need to know immediately. Cloudflare’s analytics or server-level tools like GoAccess can show this in real time.

Tying It All Together: A Security Checklist You Can Use Today

Here’s a prioritized list. Do these in order:

☐ Verify SSL auto-renewal works (check your cert expiry date right now)
☐ Set up SSL monitoring with UptimeRobot or Oh Dear
☐ Run SSL Labs test and fix anything below an A rating
☐ Configure offsite backups to S3 or Backblaze B2
☐ Test a full restore on a staging server
☐ Install server-side malware scanning (Wordfence, ImunifyAV, or similar)
☐ Set up a remote scanner on a weekly schedule
☐ Put Cloudflare or a similar proxy in front of your site
☐ Block xmlrpc.php if you’re on WordPress
☐ Configure rate limiting on login and admin endpoints
☐ Add HSTS headers (start with a short max-age)
☐ Document your incident response plan and store it somewhere you can access even if your site is down

This entire list takes about 3-4 hours to work through for a typical site. That’s a small investment against the $23,000 my client lost, not counting the long-term customer trust damage that’s impossible to quantify.

Pick the Right Host for Your Security Needs

Your host’s built-in security features matter, but they’re not a complete strategy. The best hosting providers give you a solid foundation—auto-renewing SSL, daily backups with easy restores, server-level malware scanning, and network-level DDoS filtering. You build on top of that with tools like Cloudflare, offsite backups, and application-level protections.

Compare hosts based on their actual security implementations, not marketing bullet points. Check our hosting comparison tools to see which providers include these features at each price tier, and read the fine print on what “DDoS protection” actually means for each one.

Disclosure: Some links on this page are affiliate links. We may earn a commission if you make a purchase, at no extra cost to you. This helps us keep the site running and produce quality content.