Backup files accidentally left in web-accessible directories are one of the most common causes of critical data breaches. A single accessible database dump delivers every user credential, email address, and private record in your system to an attacker — without requiring them to exploit a single vulnerability in your application code. Backup files appear on production servers constantly, across all types of sites and hosting setups, and attackers probe for them systematically.
How Backup Files End Up on Web Servers
Backup files appear in web-accessible directories through a small number of predictable scenarios:
- Manual backups before risky changes: A developer runs
cp wp-config.php wp-config.php.bakbefore editing configuration. The backup sits in the web root indefinitely. - Automated backup scripts with wrong output paths: A cron job writes the database dump to
/var/www/html/backup.sql(inside the document root) instead of/var/backups/(outside it). - Deployment artifacts left in place: A ZIP archive created during deployment is unpacked and the archive itself never removed.
- Text editor temporary files: Vim creates swap files (
.wp-config.php.swp); Emacs creates backup files (wp-config.php~). These are generated automatically and frequently forgotten. - FTP uploads for temporary storage: A backup is uploaded for a specific task, then never moved or deleted.
The common thread: each scenario involves a developer taking a reasonable local action without considering that the web server will serve any file inside the document root that matches a request — it has no concept of "this file is only here temporarily."
What Attackers Probe For
Backup file discovery is fully automated. Tools generate requests for hundreds of filename patterns across common paths. The categories that yield results most frequently:
Database dumps
database.sql, backup.sql, db.sql, dump.sql, mysql.sql, site.sql, data.sql, and variants using the site's domain name as a prefix. A database dump typically contains the complete users table with hashed (or plaintext) passwords, all customer records, order history, and every other table in the application.
Configuration backups
wp-config.php.bak, wp-config.php.old, wp-config.php~, config.php.bak, settings.py.bak, .env.bak, database.yml.bak. Configuration backups contain database credentials, API keys, and secret tokens in plaintext — immediate critical exposure that enables direct database access bypassing the application entirely.
Archive files
backup.zip, site.zip, www.zip, backup.tar.gz, site.tar.gz, html.zip. Archive files frequently contain the complete application source code, all configuration files, and sometimes a database export — equivalent to handing an attacker your entire application.
Source code backups
index.php.bak, app.js.old, functions.php.bak, main.py.bak. These let attackers read application logic without executing it — useful for finding additional vulnerabilities, hardcoded secrets, or proprietary business logic.
What Attackers Do With These Files
A single accessible database dump enables: account takeover via password hash cracking, enumeration of all user emails for targeted phishing campaigns, extraction of payment information if stored in the database, and creation of breach notification obligations under GDPR or CCPA. A configuration file with database credentials enables direct database connection — an attacker can download the entire database in seconds without touching the web application. An API key found in a backup file is usable immediately against third-party services (AWS, Stripe, Twilio) and remains valid until explicitly rotated.
How to Audit Your Own Server
To check your document root for exposed backup files, run this from your server:
find /var/www/html -name "*.bak" -o -name "*.old" -o -name "*.sql" -o -name "*.tar.gz" -o -name "*.zip" -o -name "*~" -o -name "*.swp"
Then verify whether each result is publicly accessible: curl -I https://yoursite.com/filename — an HTTP 200 response means the file is live and accessible to anyone.
Prevention
- Store backups outside the document root. Write backup scripts to output to
/var/backups/, a private cloud storage bucket (S3 with private ACL, not public), or a separate backup server — never inside/var/www/html/. - Block backup extensions at the web server level. Add a deny rule for common backup file patterns in Nginx:
location ~* \.(sql|bak|old|tar|gz|zip|swp|tmp)$ { deny all; } - Do not use robots.txt to hide backup paths. A Disallow entry advertises the path. The correct control is a web server deny rule or physical removal from the document root.
- Run regular automated scans that probe for backup file patterns, so any newly created backup file is detected before attackers find it.
How Shieldome Probes This
Shieldome checks for backup file exposure as part of its Insecure Design (OWASP A04) scan. When you run a Shieldome scan, it sends HTTP requests to 25+ backup file patterns across your domain root and common subdirectories:
- Database dumps:
database.sql,backup.sql,db.sql,dump.sql,site.sql - Configuration backups:
config.php.bak,wp-config.php.old,settings.py.bak,.env.bak - Archive files:
backup.zip,site.tar.gz,www.zip - Source code backups:
index.php.bak,app.js.old,functions.php.bak - Editor artifacts:
wp-config.php~,.wp-config.php.swp
Any HTTP 200 response is flagged as a Critical severity finding. The finding detail includes the exact URL, the HTTP status returned, and the Content-Type header — giving you the specific file to remove or block.
Frequently Asked Questions
How quickly can attackers find an exposed backup file?
Automated tools scanning for common backup filenames run continuously across the internet. A file placed in a web-accessible location can be found within hours. Assume the window between a backup file appearing in the document root and an attacker probing for it is measured in hours, not days.
Is a password-protected ZIP file safe to leave on a web server?
No. ZIP password protection uses weak encryption in most implementations, and common ZIP passwords can be cracked quickly with modern tooling. The filename and file size are also visible without the password, which reveals information about the archive contents. Sensitive backup files should never be stored in web-accessible locations regardless of password protection.
What should I do if I find that a backup file was exposed?
Remove the file immediately, then treat it as a confirmed data breach: rotate all credentials and API keys that may have been contained in the file, force password resets for affected user accounts, review access logs to determine how long the file was accessible and whether it was downloaded, and assess breach notification obligations under applicable regulations.
Can I use robots.txt to hide backup files?
No. Adding backup file paths to robots.txt advertises their location to anyone who reads the file — including attackers. robots.txt is a public document that security scanners fetch in their first reconnaissance step. The correct control is a web server deny rule or physical removal from the document root.
What is the difference between a web server deny rule and storing backups outside the document root?
Storing outside the document root is more robust. Web server configuration can be overridden by subsequent deployments, application code, or configuration mistakes. A file physically outside the document root cannot be served by the web server under any configuration — there is no code path that can accidentally expose it. Use both controls together where possible: store backups outside the root as the primary control, and add deny rules as defense in depth.
How do I securely store database backups in production?
The standard approach: encrypt the dump before storing it (using GPG with a strong asymmetric key), write it to a private cloud storage bucket with no public access policy and restricted IAM access, set a retention policy that automatically deletes backups older than your recovery window, and restrict access to the backup location to specific IAM roles or IP addresses. Never store unencrypted database dumps anywhere a web server process can read them.
Backup file exposure costs nothing to fix and can cost everything to recover from. Run a free Shieldome scan to check whether your site is accidentally exposing backup files, configuration archives, or database dumps.