Hosting Guide

When Isolation Matters More Than Hardening

Hardening tries to prevent breaches. Isolation contains them. For sites where a breach is likely rather than merely possible, containment is the more valuable security property.

Overview

Security hardening assumes that if defenses are strong enough, breaches won't happen. Isolation assumes that breaches will happen and limits what they can reach. These are not competing approaches — they are complementary. But for sites managing multiple properties or handling data where breach propagation is the primary risk, isolation provides a guarantee that hardening cannot.

How to think about it

Isolation separates systems so that a failure in one cannot propagate to another. In hosting, isolation means a compromised site cannot access another site's files, database, or execution environment. The compromise is contained within the boundary of the isolated unit.

Hardening reduces the probability of compromise. Isolation reduces the consequences when compromise occurs. Both matter. Isolation is specifically more valuable when: there are multiple sites to protect, a single compromise affecting all of them would be catastrophic, or the threat model includes targeted attacks that skilled defenders might fail to prevent.

The practical difference: on shared hosting without isolation, a compromised neighboring account can potentially access other accounts' files and inject malicious code. With container isolation, each account's files, processes, and execution environment are inaccessible to others. The compromise of one site doesn't enable the compromise of others.

How it works

Process isolation: each account's PHP processes run under a separate user identity. File access is restricted to that user's directory. A malicious script that gains code execution can only access files owned by that user — not neighboring accounts.

Container isolation: each site runs in a separate container with its own filesystem, process space, and network namespace. Compromise of the container cannot directly access resources outside it. This is a stronger isolation model than process isolation and is the approach used by managed WordPress platforms on cloud infrastructure.

Database isolation: each account's database is accessible only by that account's credentials. On shared hosting without proper isolation, database credentials stored in configuration files readable by neighboring accounts create potential lateral movement opportunities.

Where it breaks

Isolation doesn't help when the attack is within the isolation boundary. A compromised admin account, a malicious plugin installed by the site owner, or an application vulnerability that allows arbitrary code execution — all of these operate within the isolated environment. The compromise is contained from the outside; it isn't prevented from the inside.

Isolation also doesn't help against attacks on shared infrastructure layers that exist above the isolation boundary — network-level attacks, hypervisor vulnerabilities, or control plane compromises. These are rarer but represent the category of attack where isolation fails to protect.

In context

Budget shared hosting: minimal or no isolation between accounts. A compromised account may have access to neighboring account files depending on server configuration. The shared execution environment creates lateral movement opportunities.

Above-average shared hosting: process-level isolation with proper user separation. Neighboring accounts can't directly access each other's files. Database credentials are isolated. The isolation is meaningful but not as strong as container-level separation.

Container-isolated hosting: each site in a separate container with its own execution environment. The strongest isolation model available in web hosting. A compromise of one site has no path to neighboring sites through the hosting infrastructure.