By default the component uses a non secure location to store its backup files and temporary files, within
your site's file system hierarchy, namely
location is well known and can be - theoretically - accessed directly from a web browser. Since the backup
output directory stores the results of your backup attempts, that is SQL files containing database backups and
archive files containing all of your site, a malicious person with access to this location could steal sensitive
information or compromise your site's integrity.
The first line of defense, is to use mangled, hard to guess, names for the SQL backup. However, in the era of multi-MbPS xDSL Internet connections and scripting, it wouldn't take an attacker that long to figure out the filename. Remember: security through obscurity is no security at all!
As a second line of defense, we include a secure
.htaccess on the default backup
output directory to disable direct web access. However, this is only possible on Apache-powered web servers
which allow the use of
.htaccess files. You should check with your host to ensure that this
kind of protection is possible on your site.
However, this is not enough. Security experts argue that storing backups within the potentially vulnerable system itself might be a security risk. It is possible that a malicious person could gain access via other means. Think of a simple scenario. You have an Administrator with a weak password a hacker eventually guesses. Now the hacker can log in to your site, but doesn't have access to the component. Despite that, you have installed a file administration component, such as eXtplorer, which allows administrators to browse the site's file system and download files. How long would it take before your site got compromised? Right. Not very long indeed!
The best approach is to use a directory which is outside your web server's root. By definition, this is not directly exposed to the web and is usually unavailable to file administration utilities.