Any project we are working on should always have some type of development environment where we can test code before we take it live (aka “in production”). In reality, this is not always the case due to resource or time constraints. When working on live sites we don’t want to make mistakes but unfortunately there is a huge mistake we can make while trying to avoid mistakes. This mistake is making backups of files and leaving those backups on the live server, accessible to the world.
But how would anyone know where to look for them? you might ask. Well, they can guess. Us humans are surprisingly predictable and assuming a pattern of behavior can obviously yield results. Otherwise the “bad guys” wouldn’t keep trying. I recently reviewed my access logs. Judging by the assumptions made by the hackers, these are the names that people have used in the past when making live backups of their WordPress config file (wp-config.php).
Examples of wp-config backup file scans:
wp-config.php~
wp-config.php.bak
wp-config.php.save
wp-config%20fix.txt
wp-config-backup1.txt
wp-config
wp-config.phpOLD
wp-config.txt
wp-config.phpa
wp-config.old
wp-config.php.txt
wp-config.
wp-config-backup.txt
wp-config-backup
config.bak
Remember that only files ending in .php will be executed before they are served so the examples above deliver all your WordPress database information in plain text format to anyone who were to access those files. If you think you may have done this on a WordPress site in the past, you better undo it asap. If it was a long time ago, there is a big risk the site is now hacked. Ideally, you should not be leaving any backup files on the live site at all. It takes up space can cause confusion for other developers about which files are actually in use. If you have a good reason to leave backups of files on the live server, make sure you put them below the root (public_html/www) so that they are not accessible to the world.
I’ll add that whether database credentials can be used to compromise your site will depend on configurations on that specific server. If the server only allows database connections from localhost, database credentials alone are not enough to hack a site. Unless of course you’ve reused your database password (used the same password for your control panel or WordPress admin). Hopefully you’ve never done that. 🙂