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 related 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 similar 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:
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.