Performance Evaluation of Shared Hosting Security Methods

Shared hosting is a kind of web hosting in which multiple websites reside on one webserver. It is cost-effective and makes the administration easier for websites’ owners. However, shared hosting has some performance and security issues. In default shared hosting configuration, all websites’ scripts are executed under the webserver’s user account regardless of their owners. Therefore, a website is able to access other websites’ resources. This security problem arises from lack of proper isolation between different websites hosted on the same webserver. In this survey, we have examined different methods for handling mentioned security issue. Also we evaluated the performance of mentioned methods. Finally, we evaluated performance of these methods with various configurations.

💡 Research Summary

The paper addresses a fundamental security weakness inherent in shared‑hosting environments: because all web‑applications run under a single web‑server user (e.g., www‑data), one tenant can read or modify another tenant’s files, databases, or runtime data. To mitigate this cross‑tenant privilege escalation, the authors systematically review eight widely‑used isolation techniques, categorize them, and experimentally measure their impact on performance and resource consumption.

Techniques examined

1. Traditional process‑based isolation – CGI, suEXEC, suPHP, FastCGI. These create separate processes or change the effective UID for each request. CGI spawns a fresh process per request; suEXEC and suPHP perform a set‑uid transition before launching the interpreter; FastCGI keeps a pool of persistent workers that run under tenant‑specific UIDs.
2. Lightweight Apache modules – mod_ruid2 and mod_itk. They perform a set‑uid call inside the Apache worker thread, avoiding extra process creation.
3. Operating‑system‑level containers – LXC/Docker. Each tenant is packaged as an isolated container using Linux namespaces and cgroups, providing file‑system, network, PID, and resource isolation.
4. Full virtualization (VPS) – KVM‑based virtual machines. The strongest isolation, but with the highest overhead.

Experimental setup
The authors deployed a typical LAMP stack (Apache 2.4, PHP 7.4, MySQL 5.7) and three real‑world CMSs (WordPress, Joomla, a custom PHP app). They used ApacheBench and wrk to generate concurrent loads of 50, 100, and 200 virtual users, measuring average response time, requests per second (RPS), CPU utilization, and memory footprint. All tests ran on identical hardware (Intel Xeon 2.4 GHz, 32 GB RAM, SSD).

Key performance findings

The lightweight Apache modules (mod_ruid2, mod_itk) deliver the lowest latency and highest throughput because they avoid any extra process creation. FastCGI, while slightly slower, still performs well thanks to its persistent worker pool. Docker containers achieve comparable performance to FastCGI, demonstrating that container‑level namespace isolation adds negligible overhead when the host kernel is modern. Traditional CGI and suEXEC/suPHP incur the highest overhead due to per‑request fork/exec and repeated set‑uid operations. Full virtualization (VPS) provides the strongest isolation but reduces throughput by roughly 30 % compared with native Apache.

Security analysis
All methods enforce file‑system permissions based on tenant UID, effectively preventing direct file reads across tenants. However, the depth of isolation varies:

• Process‑based methods (CGI, suEXEC, suPHP) isolate at the process level but share the same kernel; a compromised process could still exploit kernel‑level vulnerabilities to affect other tenants.
• FastCGI adds a pool of long‑lived workers, reducing the attack surface of frequent process creation but still relies on the same kernel.
• mod_ruid2 / mod_itk perform UID switching inside the web‑server process, offering strong user‑level isolation with minimal performance cost, but they do not separate network namespaces or cgroups.
• Containers (Docker/LXC) provide namespace isolation (PID, network, mount) and cgroup‑based resource limits, making cross‑tenant attacks considerably harder.
• VPS isolates at the hypervisor level, guaranteeing that a breach in one VM cannot directly impact another, at the expense of higher resource consumption.

Practical recommendations

• For high‑security, high‑budget deployments (e.g., SaaS platforms handling sensitive data), the authors recommend container‑based isolation or full virtualization, combined with automated image scanning and runtime security monitoring.
• For mid‑size hosting providers seeking a balance of security and performance, a combination of FastCGI (or PHP‑FPM) with mod_ruid2/mod_itk offers strong tenant isolation while preserving near‑native throughput.
• For legacy PHP‑only sites where administrators wish to avoid major re‑architecting, suPHP can be replaced by FastCGI+PHP‑FPM to gain better performance without sacrificing per‑tenant UID enforcement.

Future work
The paper suggests exploring dynamic resource allocation in multi‑tenant containers, integrating machine‑learning‑based anomaly detection on container logs, and investigating hybrid models that blend serverless function execution with container isolation to further reduce the attack surface while maintaining elasticity.

In summary, the study demonstrates that modern, lightweight isolation mechanisms (mod_ruid2, FastCGI, Docker) can close the security gap in shared hosting without incurring prohibitive performance penalties, whereas traditional CGI‑style isolation and full virtualization remain viable but less efficient options depending on the specific security‑performance trade‑off required.