Exposed Backup Scanner

How this check works

Scanaris requests nine file names people use over and over to store backups in the web root: backup.zip, backup.tar.gz, website.zip, www.zip, public_html.zip, site.zip, database.sql, dump.sql and db.sql. For each one it checks that the response is a real file and not your site's generic page: it looks at the content type and, for SQL dumps, that the text looks like SQL. All findings are critical, because such a file contains either the site's full code or the whole database.

Why it matters

A reachable backup.zip is your complete project: code, configuration, whatever keys were in the files and, often, a copy of the database inside. A dump.sql is the database as is: users, emails, hashed passwords (which can be attacked at leisure), orders, messages. No technique is needed: it is a download. And automated scanners try exactly these names against every domain they find, so "nobody knows the URL" is not a protection.

Why it happens

Out of convenience at a bad moment: before a migration or an update the site folder gets zipped "just in case" and left right there. Or a backup plugin writes to a public folder. Or a database export is saved next to the code to hand it to someone. On a server that serves the project root, any file that lands there is public instantly.

How to fix it

• Delete the file now and act as if it had been downloaded: rotate every key and password it contained and, if there was personal data, consider the obligation to notify.
• Move backups out of the public directory. Backups go to separate storage (a private bucket, another server), never to a folder the web server serves.
• Configure the backup tool to write outside the web root. WordPress plugins usually let you choose the folder or send to an external service.
• Block the extensions on the server as a second barrier. In nginx: location ~* \.(zip|tar|gz|sql|bak)$ { deny all; }. In Apache, an equivalent FilesMatch with Require all denied. If you legitimately offer zipped downloads, limit them to a specific folder.
• Review the access logs for requests with 200 to these names: they will tell you whether someone got there first.

Check it is fixed

for p in backup.zip backup.tar.gz website.zip www.zip public_html.zip site.zip database.sql dump.sql db.sql; do
  printf "%-18s " "$p"; curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://yourdomain.com/$p"
done

Expected: 404 or 403. A 200 with text/html on a single-page application is its generic HTML; a 200 with application/zip, application/octet-stream or text/plain is the real file.

Frequently asked questions

My backup has a name nobody would guess.

Attack tools try thousands of names and combinations with the domain, the date and words like "old" or "bak". An unusual name reduces the risk but does not remove it; the fix is for it not to be in a public folder.

What if the file is password-protected?

A password-protected ZIP downloads just the same and gets attacked with unlimited attempts on the attacker's computer. It is still a critical finding.

The check only looks at the root. What about subfolders?

Correct, these nine names are tried at the root. Open directory listings, which another check measures, are the usual way to find backups in subfolders; closing them and blocking the extensions covers the rest.