WordPress Security: What Your Hosting Choice Actually Controls

Most WordPress security advice focuses on what you do inside WordPress: update plugins, use strong passwords, install a security plugin. That advice is correct but incomplete. A significant portion of WordPress security is determined by your hosting infrastructure — the layer below WordPress that no plugin can touch. Understanding that layer is what separates sites that stay clean from sites that get hacked repeatedly.

The Shared Hosting Attack Surface

When your WordPress site runs on shared hosting, it shares a server with hundreds or thousands of other websites. This creates attack vectors that have nothing to do with your WordPress configuration.

Cross-account file access: On poorly configured shared hosts, PHP running as the same system user for multiple accounts can read each other's files. Your wp-config.php — which contains your database credentials — could be readable by other scripts on the same server. This is called a symlink attack, and it's been exploited on shared hosts repeatedly.

Resource exhaustion as a vector: A site on the same server gets infected and begins sending spam or running a crypto miner. The host detects abuse, suspends the server, and takes your site offline. You're collateral damage.

Shared IP reputation: If another site on your shared IP address gets blacklisted by Google or email providers, your site inherits that reputation. You did nothing wrong — you're at the wrong address.

Malware pivot: A compromised account on the same server can use that foothold to attempt lateral movement to other accounts. Server-level vulnerabilities (outdated OS, misconfigured permissions) can affect all sites on the machine.

None of these attacks require your WordPress installation to have a single vulnerability. They're infrastructure problems.

What Container Isolation Provides

Container-based WordPress hosting fundamentally changes the threat model. Each WordPress installation runs in its own container — an isolated Linux environment with its own filesystem, its own processes, and its own network namespace.

Filesystem isolation: A process inside Container A cannot access files in Container B. There's no symlink attack because there's no shared filesystem between tenants. Your wp-config.php is only accessible from within your container.

Process isolation: A compromised neighboring site can't list your running processes, can't inject into your PHP process, can't read your memory. The kernel enforces this at a level below what any application can override.

Network isolation: Each container gets its own virtual network interface. Other containers can't see your database traffic, can't intercept your internal service communication, and can't reach your container's localhost.

Resource limits: Even if a neighboring site is compromised and running malicious code consuming 100% CPU, your container's resource allocation is protected. CPU and memory limits are enforced by the container runtime, not by application-level throttling.

The Database Security Layer

WordPress sites are compromised through their database more often than through the application layer. SQL injection, credential theft, and database lateral movement are all significant vectors.

Connection encryption: Database connections between WordPress and MySQL should use TLS in transit. On shared hosting, traffic between the web server and database server often crosses internal network segments that aren't encrypted. Container platforms that co-locate WordPress and MariaDB on the same host network eliminate this risk — the connection never leaves the host.

Dedicated database credentials: Each WordPress installation should have its own database user with permissions scoped to a single database. Never use root credentials in wp-config.php. On shared hosting, this is often done correctly but can't always be verified. On a container platform, each deployment gets its own MariaDB container with isolated credentials.

Database port exposure: MySQL should never be accessible from the public internet. On container platforms, databases run on a private internal network — port 3306 isn't exposed externally. On shared hosting, the database server configuration is opaque; you're trusting the host has configured it correctly.

SSL/TLS: Beyond the Padlock

Every WordPress site needs HTTPS. This is table stakes. What's less discussed is how TLS is implemented and maintained:

Certificate automation: Let's Encrypt certificates expire every 90 days. Missed renewals cause browser security warnings that immediately tank traffic. Properly managed hosting platforms renew certificates automatically, typically 30 days before expiry, with zero downtime. Shared hosts vary widely on this — some automate it, some require manual renewal, some charge for it.

TLS version and ciphers: TLS 1.0 and 1.1 are deprecated and insecure. Properly configured servers use TLS 1.2 minimum, TLS 1.3 preferred. Check your configuration with SSL Labs (ssllabs.com/ssltest). A score below A indicates misconfiguration that a good managed host shouldn't allow.

HSTS: HTTP Strict Transport Security tells browsers to always use HTTPS for your domain, preventing SSL stripping attacks. Set it in WordPress with a plugin or in your Nginx/Apache config. Your hosting platform controls whether this header can be set correctly.

WordPress-Level Security: The Right Practices

With solid infrastructure in place, these WordPress configurations close the remaining attack surface:

wp-config.php Hardening

// Move wp-config.php one directory above the web root
// Most managed platforms do this automatically

// Disable file editing via the admin dashboard
define('DISALLOW_FILE_EDIT', true);

// Disable plugin and theme installation from admin
define('DISALLOW_FILE_MODS', true);

// Force SSL for admin area
define('FORCE_SSL_ADMIN', true);

// Limit post revisions to reduce database bloat and attack surface
define('WP_POST_REVISIONS', 5);

DISALLOW_FILE_MODS is particularly important: it prevents an attacker who gains admin access from immediately installing a malicious plugin or modifying theme files to execute arbitrary PHP.

Login Security

WordPress's /wp-login.php endpoint is one of the most targeted URLs on the internet. Brute-force attacks against WordPress login are constant background noise. Countermeasures:

Rate limiting at the server level: The most effective protection is blocking repeated failed login attempts at the Nginx/Apache level before PHP even loads. Your hosting platform should support this. If it doesn't, apply-level rate limiting via a plugin is the fallback.

Two-factor authentication: Required for all admin accounts. Wordfence, Jetpack, or WP 2FA all implement this correctly. This single measure prevents the vast majority of successful brute-force attacks from becoming full compromises.

Limit login attempts: Lockout accounts after 5 failed attempts. The WP Lockdown or Limit Login Attempts Reloaded plugins handle this.

Custom login URL: Obscuring /wp-login.php behind a custom URL eliminates automated scanning. Not a security control on its own — any attacker who knows you're running WordPress will know to try your custom URL — but it eliminates low-effort automated attacks.

File Permissions

Correct WordPress file permission model:

WordPress directories: 755 (rwxr-xr-x)
WordPress files: 644 (rw-r--r--)
wp-config.php: 600 (rw-------)
.htaccess: 644 (rw-r--r--)

PHP should never be able to write to anything except wp-content/uploads. If WordPress's update mechanism requires 777 permissions on core files, your hosting platform is misconfigured. Proper deployments run PHP as a user that can write to uploads only, with core files owned by a different system user.

XML-RPC

xmlrpc.php enables remote WordPress publishing and is used by the Jetpack plugin. It's also a brute-force amplification vector — a single request to XML-RPC can attempt thousands of login combinations. Unless you specifically use XML-RPC-dependent functionality:

// functions.php or mu-plugins
add_filter('xmlrpc_enabled', '__return_false');

Or block it at the server level:

location = /xmlrpc.php {
    deny all;
}

REST API Exposure

The WordPress REST API (/wp-json/) exposes your user list by default at /wp-json/wp/v2/users. This gives attackers valid usernames to target with brute force:

// functions.php
add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

Malware and Compromise Recovery

If your WordPress site gets compromised, recovery steps:

1. Take the site offline immediately — a compromised site is actively harmful to visitors (malware downloads, phishing, spam relays)
2. Reset all credentials: WordPress admin passwords, database credentials, SFTP/SSH passwords, hosting account password
3. Restore from a clean backup — not a recent backup (it may contain the compromised files), but one from before the compromise
4. Identify the entry point — without knowing how the attacker got in, they'll get in again
5. Update everything: WordPress core, all plugins, all themes
6. Scan clean files — compare your installation against fresh WordPress downloads using a file integrity checker

The most important item is number 3. Patching a live compromised installation is unreliable — backdoors planted by attackers can be hidden anywhere, including in database rows or encoded inside image files. A clean restore is the only reliable recovery.

Automated Backups as Security Infrastructure

Backups aren't just disaster recovery — they're the most important security control you have. A clean backup from before a compromise is worth more than any security plugin.

Backup requirements:
- Daily automated backups at minimum; weekly is inadequate for active sites
- Off-site storage — a backup on the same server as your site is compromised along with the site
- Database + files — both wp-content and the database, not just one
- Tested restores — a backup you've never tested restoring from is an untested assumption

Container-based managed hosting platforms that include automated daily backups eliminate one of the most common gaps in WordPress security posture. Most compromised sites that stay compromised for weeks or months are running without backups — the cost of a clean restore is too high, so the owner patches over the compromise instead.

The Hosting Decision Is a Security Decision

Choosing shared hosting over containerized hosting is a security tradeoff that no number of WordPress security plugins can fully compensate for. The attack surface introduced by sharing server infrastructure with unknown neighbors, the opacity of shared file permissions, and the inability to enforce strict process isolation are structural problems.

Container-based hosting doesn't eliminate WordPress security work — plugin updates, strong passwords, login protection, and backups still matter. But it eliminates an entire class of attacks that originate outside your WordPress installation, and it gives you a stronger foundation for the security controls you do apply.

Infrastructure security and application security compound. Get both right.