Most WordPress security advice focuses on what you do inside WordPress: update plugins, use strong passwords, install a security plugin. These things matter. But the hosting environment is an equally important layer — and one that most site owners never evaluate.
A WordPress site's security can be thought of in two distinct layers: what happens inside WordPress (your plugins, your configuration, your credentials) and what happens at the hosting environment level (your server, your network, your PHP configuration).
Security advice overwhelmingly focuses on the first layer because that's what site owners have direct control over through the WordPress dashboard. The second layer is often invisible — you can't see what PHP version your host is running, or whether wp-login.php is rate limited at the server level, or whether your account is isolated from compromises on neighbouring sites.
Traditional shared hosting places many customer sites on the same server with access to the same underlying resources. When one account is compromised, it can potentially be used to probe other accounts on the same server — reading files in accessible directories, leveraging shared database connections, or using the server's outbound network connection to attack other sites.
Properly isolated hosting environments restrict each site to its own resources: its own filesystem, its own process space, its own network namespace. A compromised site on the same physical machine can't access another site's files or database because those resources aren't reachable from within the isolated environment. The boundary between sites is enforced at the operating system level, not by configuration that can be misconfigured.
Running an end-of-life PHP version means running software with known, unpatched vulnerabilities. These vulnerabilities are in the PHP interpreter itself — below all the WordPress-level security you apply. Current PHP (8.1 and 8.2 are in active support in 2023) receives security patches; older versions don't.
Rate limiting on wp-login.php applied at the web server level (before PHP executes) stops brute-force attacks from consuming server resources, regardless of what WordPress plugins are installed. A WordPress security plugin applying rate limiting in PHP still loads all of WordPress for each attempt. Server-level rate limiting stops the request before any PHP runs.
HTTP security headers — X-Frame-Options, X-Content-Type-Options, Content-Security-Policy — are browser-side protections against clickjacking, MIME type confusion, and cross-site scripting. These are most reliably configured at the web server level, applied to every response regardless of which WordPress plugin or theme generated it.
Most hosting providers don't volunteer this information — you need to ask:
"We recommend installing Wordfence" is a non-answer to the rate limiting question. "We apply Nginx rate limiting to wp-login.php at 10 requests per minute" is an answer. If your provider can't answer clearly, the protection may not exist.
Some hosting-level security is simply not accessible to site owners: the PHP version on a shared host is typically set by the provider, server-level firewall rules are managed by the provider, and account isolation is an architectural property of the hosting platform.
Choosing a hosting provider with the right architecture is a security decision that site owners make once — but it establishes the floor for everything else. WordPress-level security improvements are meaningless if the hosting environment is compromised.
DownUnder WP is built around isolation and server-level security as baseline features. Each site runs in its own environment, rate limiting is applied at the Nginx level, PHP is current, and security headers are set on every response. The hosting environment handles what the hosting environment should handle.
Australian WordPress hosting from $5/month
Your own containerised environment on Australian NVMe servers. Simple, fast, and genuinely cheap.