There is a very common misconception that moving configuration.php outside of your Joomla! root somehow makes your site more secure. It’s so common that you can even find instructions on the Joomla! documentation wiki. Let’s separate the myth from the facts and let’s see why this “security” advice may not be as secure as one might think.

It does cause trouble

First, let’s begin with the drawbacks of moving your configuration.php file outside of the Joomla! root. The first obvious problem is that if you have a site which has to use Joomla!’s FTP layer to write to files on the server you can no longer edit your configuration.php file. I mean, you can edit the configuration in Global Configuration, but nothing will be written as Joomla! won’t be able to use FTP to write to the file. Even worse, on Joomla! 1.5 sites –which modify the configuration.php file itself to use require() to load the real file– it’s outright impossible using the Global Configuration. This can be disastrous if, for example, you want to emergently put your site off-line or if you have to modify a configuration setting from a device which doesn’t have an FTP client, like your iPad just 10 minutes before boarding your flight across the Atlantic.

The other not-so-obvious issue is that you will lose a great deal of functionality in Akeeba Backup. The restoration script keeps your settings only if there is a configuration.php file in the site’s root. This happens because we can’t load the Joomla! Platform when doing a restoration. We can’t because it’s possible that you or some third party component has modified a core file, causing a server error when you restore the site to a different location.

Why it’s not really secure

Now that we are aware of the issues, let’s see why people suggest that you should move that file off the site’s root in the first place. The idea is that if the configuration.php file is outside the web site’s root it can’t be read by hackers. This is a false assumption with only a very narrow exception.

First, the exception. The only practical case where moving the configuration.php file outside the site’s root may save you is if you’re on a host using an ancient version of PHP CGI which affected by a grave security issue. However that would mean that you’re on a host which is using outdated server side software. In that case, if I were you, I’d be more much worried about hackers cracking the server where your site is hosted, not just your site. Another exception is that the attacker is able to upload a PERL or other supported CGI script to your site and gain access to your site’s files. However, as we’ll see later on, in this case moving the configuration.php file will be rather useless as the attacker can still read it.

The very notion that moving your configuration.php file outside your site’s root can prevent hackers from reading its contents is misguided to say the least. I will now present all the ways a hacker can still read the contents of the file using the most common attacks I’ve seen being used to hack sites. The basic premise of all of these attacks is that since Joomla! can read the file (otherwise it wouldn’t work!) so can a hacker.

On some vulnerable sites it’s possible to exploit an extension to run arbitrary code inside Joomla!. The most common attack method is Remote File Inclusion. It’s sufficient for the attacker to run this simple code:

<?php $asdfasdf = new JConfig; 
echo "<pre>"; var_dump($asdfasdf); 
die("</pre>");

Since the code executes inside Joomla! we end up dumping the contents of configuration.php without having to care where it’s stored. You are pwned.

OK, let’s go to a different kind of attack: Directory Traversal. The idea behind this attack is that you can manipulate a vulnerable extension to dump the contents of an arbitrary file on the server. The first attempt will be dumping configuration.php on the site’s root. Not being found, the hacker will try dumping defines.php in the site’s root or, if it doesn’t exist, includes/defines.php. This reveals the location of the configuration.php. From that point it’s trivial dumping its contents. Sorry to say that again, but you’re pwned.

The most common attack vector is actually another compromised site (it doesn’t even have to be a Joomla! site!) on the same server and lax permissions, or an attacker exploiting a vulnerable script to upload a C99 variant script. In both cases the attacker is able to read/write your site’s files. The possibilities are endless! He can simply read your defines.php file and figure out where the configuration.php file is and read it. He can add code to another component’s view and dump the JConfig class like I showed above. He can even write a script based on JWebApplication to dump the configuration.php file. The thing is, as soon as the hacker has filesystem access to your site, you’re pwned.

Finally, another attack. Somehow the attacker gains access to your site’s back-end. It’s not so hard to be in one of the many compromising situations leading to session hijacking. Or have your password brute-forced or stolen. As long as the hacker has access to your site’s back-end it’s easy to simply go to Global Configuration and save the page’s source code. Notice something? Your passwords are there, in plain-text. Or he can upload a tool like eXtplorer to navigate through your site. Or he can upload a fake component whose only purpose is to dump your configuration.php file (it’s trivial if you have half a brain and know how Joomla! works, like hackers do). As long as the hacker has back-end access, you’re pwned.

Conclusion

Moving your configuration.php file outside the site’s root does not make it unreadable to hackers. At best, it will make unwriteable. In Joomla!’s case there is no huge risk in writing to the configuration.php file. The biggest risk is in reading its contents and this method does not protect you from this. It will only give you a false sense of security. It will also make it harder for you to use Global Configuration feature of Joomla! and hinder the restoration of your site. IMHO it’s a “security” measure with very limited practical use while greatly increasing the frustration level of working with your site. If you have a different opinion I’ll be happy to read your opinion in the comments below.