Exposed Backup Files (.bak, .sql, .zip)
Backup archives and .sql dumps left inside the web root can be downloaded by anyone — including your entire database.
What is Exposed Backup Files (.bak, .sql, .zip)?
When a developer or admin needs a quick copy, the fastest path is often dumping the database or zipping the site "just for a minute" into the web root: backup.zip, db.sql, site-2026.tar.gz, index.php.bak, wp-config.php~. Those minutes turn into months. Automated scanners request thousands of predictable backup filenames on every host they touch, and web servers happily serve whatever archive matches. A single .sql dump contains every user, password hash, and order in your database; a site archive contains source code and, frequently, the .env file with all credentials.
Why It Matters to Your Business
An exposed backup is functionally equivalent to handing attackers your source code and a full database copy — hashed passwords for offline cracking, PII subject to breach-notification law, internal business data, and credentials that open further doors. Because backups are snapshots, they also contain OLD secrets that teams forgot they ever used, which still work in forgotten systems. GDPR fines and contractual breach clauses apply to the leak regardless of how careless vs. malicious the exposure was.
How to Fix It
1. Remove every backup/archive/dump from the web root NOW: *.zip, *.tar.gz, *.sql, *.bak, *.old, *~ of any file. Move them off the server or into storage outside /public.
2. Deny dangerous extensions at the server level so this can never recur:
Nginx:
location ~* \.(sql|bak|old|tar|gz|tgz|zip|rar|7z)$ { deny all; return 404; }
Apache:
<FilesMatch "\.(sql|bak|old|tar|gz|tgz|zip|rar|7z)$">
Require all denied
</FilesMatch>
3. Set up proper automated backups: nightly database dump + offsite object storage (S3, Backblaze) with server-side encryption and a retention policy — never into the web root.
4. Rotate any credentials that appeared in old backups. A dumped password hash from 2023 is still your user's password today if nobody changed it.
Frequently Asked Questions
Why is an exposed backup rated critical?
Because a backup usually contains everything at once: the full database (users, password hashes, orders), the source code, and the configuration with all credentials. One file equals a complete breach — no further vulnerability needed.
How do attackers find backup files with random names?
The names are rarely random: site.zip, db.sql, backup-2026.tar.gz, file.bak. Scanners brute-force thousands of such patterns on every host. Only a truly random name slows this down, and it is still served if requested — blocking the extensions is the actual fix.
Where should backups live instead?
Outside the web root entirely: a separate backup directory inaccessible via HTTP, or better, encrypted object storage (S3/Backblaze) with versioning and defined retention. The web root must contain only what the site needs to serve requests.
Technical Classification
| OWASP Category | A05:2021 — Security Misconfiguration |
| CWE ID | CWE-200: Exposure of Sensitive Information |
| Detected By | backup_files, sensitive_paths scanner(s) |
| Severity Level | critical |
How 2MNY Security Can Help
Check if your website has this vulnerability
Our backup_files, sensitive_paths scanner checks for this issue automatically.
Scan My Website FreeRelated Vulnerabilities
Exposed .git Directory
The .git directory is publicly accessible, allowing attackers to download your entire source code repository.
Server Version Disclosure
The Server and X-Powered-By headers disclose the server software and version, helping attackers target known vulnerabilities.
Directory Listing Enabled on Web Server
The web server lists directory contents to anyone, exposing unlinked files such as backups, archives and internal documents.
Exposed .env File (Config Disclosure)
The .env file is downloadable from the web, leaking database passwords, API keys and application secrets to anyone who asks.