By default the component uses a non secure location to store its
backup files and temporary files, within your site's file system
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
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.