Backup Files Are Good but Can Be Evil

Published: 2017-01-14
Last Updated: 2017-01-14 09:37:21 UTC
by Xavier Mertens (Version: 1)
3 comment(s)

Since we started to work with computers, we always heard the following advice: "Make backups!". Everytime you have to change something in a file or an application, first make a backup of the existing resources (code, configuration files, data). But, if not properly managed, backups can be evil and increase the surface attack of your web application. Just take an example:

You maintain a Wordpress website for your company and, before changing the configuration, you make a backup of the main configuration file.

# cd /var/www/htdocs
# cp -p wp-config.php wp-config.php.bak

Alternatively, you can also archive the directory content:

# zip -r .

For the same reasons, you can also make a backup of the SQL databases or user files.

Now, you can edit them and if everything goes wrong, just revert to the previous version. Looks so far so good! But, often, people forget to protect the backup (which is created with the web site UID or a wrong umask - making it readable by anybody).

What am I talking about this? For a few days, I detected a lot of scans for "backup" files across multiple websites:


I also detected scans for files ending with a '.bak' extension or the '~' (the common way for many editors to make a backup of edited files).

To protect yourself against this problem:

  • Do not store backup files in the root of your website.
  • Delete them once the maintenance completed and that you're sure you don't need it.
  • Change the owner and access rights (use a correct umask!)
  • Encrypt them (zip -e)
  • Just store them offline!

But of course, continue to make backups of your sensitive data...

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

Keywords: backup scan website
3 comment(s)


I think I prefer a system where the system is tested on a staging server and any meaningful config changes are made there and not on a live system. Also, keep old versions in a configuration management system (CVS, SVN, GIT, ClearCase, etc.) that is properly secured.
A lot of time this doesn't work because clients want a test environment that is publicly accessible. Adding firewall rules for certain IP addresses only works when they are utilizing statics. Still no excuse for allowing backup files to be accessible on the web.
This applies not only to backups that you maintain, but also to backups that your service providers might perform. I came across a situation about two years ago where my trash collector changed online payment services. The previous payment service kept an archive of the payment site - complete with cardholder data - on a browseable directory. See

Xavier, your recommendations are solid. The only thing I would add is to make sure in your business agreements and/or due diligence, to make sure your service providers follow the same practices - and to ensure business agreements specify what happens to your data when you cease doing business with a provider.

Diary Archives