Skip to main content

Using Drupal on shared hosting... Don't!

I recently had this brief and very frustrating discussion about whether or not you should advice prospective webmasters to go with a shared hosting plan instead of a virtual private server in order to host their Drupal website. The main argument against a VPS was that a server in untrained hands is an easy target for hackers, whereas a shared hosting plan comes with a system administrator who takes care of things like security patches.

The argument that a shared hosting environment is more secure than a VPS is idiocy in the making and a good indication that the person suggesting it hasn't really given the matter a lot of thought.

Shared hosting is a relic from a time when websites consisted entirely of static HTML files and all pages were considered to be completely public. Back then, system security was simply a matter of preventing everyone, having a shared hosting account, from overwriting everyone else's files, while still allowing the webserver process to read all files.

This security concept falls flat on it's face as soon as you start using a content management system like Drupal. With Drupal, website content is no longer stored directly on the filesystem, but in an SQL database which operates independently of filesystem permissions. The credentials for accessing that database, however, are kept in a file ("sites/default/settings.php" in the case of Drupal) and since the webserver process must be able to read that file, in order to connect to the database, everyone, having an account on the webserver, could then upload a malicious PHP script that steals your credentials and takes over your website.

Things get even worse once you consider that you do not only have to trust all other customers on your shared host (which is ridiculous to begin with, since you usually don't even know them) to not attack your site, but you also have to trust them not to be compromised themselves.

Let's illustrate this problem: Assume, you want to run a webshop. This means you'll have to process credit card numbers as well as shipment addresses. In order to cut down on costs, you decide to go for a shared hosting plan. Your ISP puts you on a machine with 100 other of his customers. What do you think are the odds of one of these 100 other customers being completely clueless about system security? What are the odds of one of them catching a computer virus that installs a keylogger which sniffs passwords?
Once a single account on the webserver gets compromised, an attacker can easily upload a PHP script that scans the entire filesystem for content management systems, extracts database credentials and uses them to sneak in stealth administrator accounts into the corresponding websites.
Say hello to the nightmare of having to confess to your own customers that someone might have stolen sensitive information about them!

On a VPS, the only risk you face is from unpatched software. Compare that to shared hosting environments, where, in addition to unpatched software, every other customer is also a potential break-in point and then tell me again that shared hosting is so much safer than a VPS.

Oh and to anticipate two rather silly arguments:

  • Yes, even a shared host can have unpatched software. Shared hosting is all about being dirt cheap. You can never be sure if your cheap hoster cuts cost by being sloppy with updates (rolling out patches can become quite expensive if you have to make sure that afterwards all of your customer's websites are still fully functional).
  • PHP's safe mode is not a solution to the problem. Neither is suPHP nor any other of the isolation hacks. Drupal does not work properly with safe mode enabled and if the webserver supports any other scripting languages (e.g. PERL through the age old common gateway interface), safe mode can be completely bypassed anyway.

Everyone, who wants to run a website of his own, but is clueless about computer security is also clueless about evaluating the security mechanisms of potential hosting service providers and therefore ill-advised to buy shared hosting.