Account Isolation on Shared Hosting:What It Protects

On shared hosting, account isolation is what stops one customer's website, whether compromised or simply misbehaving, from reading, changing or slowing down another customer's site. Well-run shared servers isolate accounts at several levels: separate system users and file permissions, PHP running as each account's own user, virtualised filesystems that hide other users and system files, and per-account resource limits. Isolation protects you from your neighbours; it does not protect your site from its own weaknesses.

Layers of isolation

1. Separate system users and permissions

Each hosting account is a separate Linux user with its own home directory. File permissions stop other users from reading your files, provided permissions are sensible (files typically 644, folders 755, sensitive configuration files stricter). Permissions such as 777 undo this protection.

2. PHP running as your user

Modern shared hosting runs PHP scripts as the account's own user (for example through PHP-FPM pools per user, suPHP-style handlers, or LiteSpeed's per-user processes). A script on another account therefore runs with that account's permissions and cannot write to your files.

3. Virtualised filesystems

On CloudLinux servers, CageFS gives each user a virtualised view of the filesystem: other users' home directories and sensitive system files are simply not visible, and only safe system binaries are available. Other platforms use comparable chroot or container-style approaches.

4. Resource limits

Per-account limits on CPU, memory, processes and I/O (CloudLinux's LVE, or equivalents) stop one busy or abused account from slowing everyone else. See hosting resource limits explained.

5. Network and service protections

Server firewalls, web application firewalls, brute-force protection and malware scanning operate across the whole server, protecting all accounts.

What isolation does not do

Isolation separates accounts. It does not protect:

• sites within the same account: addon domains and subdomains in one account usually share the same user, so a compromised site can affect the others in that account;
• your site from its own vulnerabilities: an outdated plugin, weak admin password or insecure custom code is your responsibility;
• your credentials: a phished control panel password gives full access to your account;
• your data if you have no backups.

What you should still do

• Separate important sites into separate accounts rather than many addon domains in one account.
• Keep all software updated and remove unused plugins and themes.
• Use strong passwords and 2FA for the control panel and site admin.
• Set correct file permissions; never use 777.
• Keep off-server backups.
• Watch for signs of compromise; see website malware: signs and what to do.

Questions to ask a hosting provider

• Does PHP run as each account's own user?
• Are accounts isolated with CageFS or a similar technology?
• Are per-account resource limits enforced?
• Is there a server-level WAF and malware scanning?
• How are compromised accounts handled to protect others?

Example: why separate accounts matter

An agency hosts five client WordPress sites as addon domains inside one shared hosting account. One client's site uses an abandoned slider plugin with a known vulnerability. An attacker exploits it and uploads a web shell. Because all five sites run as the same Linux user, the web shell can read and modify every site's files, including the other clients' wp-config.php files with database passwords. Within days, all five sites are serving spam redirects.

If each client had a separate hosting account (for example under a reseller plan), the same compromise would have stayed inside one account. The server's isolation would have blocked access to the others. See what is reseller hosting.

How to check your own exposure

• List the sites in each account. In cPanel → Domains, see which domains share an account.
• Check permissions on sensitive files (wp-config.php, .env) and make sure folders are not world-writable.
• Look for leftover installs: old test copies, backups and unused CMS installs in the same account are common entry points.
• Review FTP and SSH accounts and remove those you no longer use.

Frequently Asked Questions

Is shared hosting less secure than a VPS?

Not necessarily. A well-isolated, professionally maintained shared server can be more secure than a poorly maintained VPS. A VPS gives stronger isolation (a separate virtual machine) but makes you responsible for the server.

Can another customer see my files?

Not on a properly configured server with correct permissions and isolation. Overly open permissions (777) can weaken that protection.

Why was my site affected when another site in my account was hacked?

Sites in the same account share a user and permissions. Use separate accounts for sites that should be isolated from each other.

Related reading

See what is shared hosting and website security basics, and compare the ServerNeed shared hosting plans.

Sources

• CloudLinux documentation: CageFS
• cPanel documentation: Security