You Zipped Your Site “Just in Case.” Now Strangers Can Download It.

You zipped your site before a redeploy, uploaded a copy to the server, and meant to remove it later. That forgotten site-backup.zip could now be one guessed URL away from anyone who finds it.

Public backup files can expose source code, database records, or credentials. The risk is easy to miss when you build quickly with AI website builders, no-code tools, or manual FTP uploads. You do not need to be a developer to make a first check. Set aside 10 to 15 minutes, and check only sites you own or have permission to assess.

Why backup files become public

A website’s web root is the folder its server makes available to visitors. Put a file in that folder, or in a publicly served subfolder, and it may be reachable through a URL.

That can turn temporary working files into permanent exposures:

• site-backup.zip may contain the whole website.
• database.sql may contain user data, password hashes, or tokens.
• .env.old may contain API keys or database passwords.
• wp-config.php.bak may include WordPress database credentials.
• index.html.bak may reveal an older version of a page.

Fast experiments and frequent redeploys leave more opportunities to forget a file. Manual uploads make it easier to copy a backup to the wrong place. And “I’ll keep a copy on the server” feels convenient until that copy sits in the public web root.

Directory listing makes the problem worse. If enabled, a visitor may see a list of files in a folder rather than needing to guess each filename. Turning listing off helps, but it does not protect a file that someone can still request directly.

A 10 to 15-minute check for your own site

1. Check your hosting files first

Open your hosting provider’s file manager or deployment area. Look in the public folder, often named public_html, www, htdocs, or public.

Search for filenames containing words such as:

backup, bak, old, copy, temp, dump, export

Look for these extensions too:

.zip, .tar.gz, .sql, .env, .bak, .old

Also check for files such as .env.old, database.sql, site-backup.zip, and wp-config.php.bak. Names vary, so search for patterns rather than relying only on these examples.

Keep backups outside the web root. Store them in your hosting provider’s protected backup service or another private location, not beside the files visitors can reach.

2. Check likely public URLs without opening sensitive files

For a site you own, you can test whether common filenames appear to be available. For example, replace yourdomain.com with your domain and check paths such as:

https://yourdomain.com/site-backup.zip
https://yourdomain.com/database.sql
https://yourdomain.com/.env
https://yourdomain.com/index.html.bak

You can also check a suspected backup folder, such as /backup/, for directory listing.

If a request appears to return a file, do not download it, open it, or share its contents. A 200 response can indicate a file was served, but some sites also return a custom “not found” page with that status. Confirm using your hosting controls or a security check, then remove or block the file. If you are unsure, ask your host to verify whether the path serves a real file.

A 403 or 404 is generally a better sign for a sensitive path, but confirm that no alternate copy exists elsewhere on the site.

3. Review server or CDN logs

Analytics tools usually track page views, not every request for a ZIP archive, database dump, or configuration file. For this check, use your hosting provider’s access logs or CDN logs if available.

Search for requests containing backup, .zip, .sql, .env, .bak, or .old. Pay attention to repeated requests, unfamiliar IP addresses, and successful responses such as 200 for paths that should never be public.

A log entry does not prove a file was successfully read, and a quiet log does not prove a file is safe. Treat logs as clues, then verify the files and access rules in your hosting setup.

4. Remove or block exposed files

Delete unnecessary backups from every public folder. If you need to keep them, move them outside the web root into private, access-controlled storage.

Ask your hosting provider how to deny public access to backup and configuration files if you cannot change server rules yourself. Do not rely on robots.txt to protect files. It is a crawler instruction, not an access-control system, and a disallowed path can still be requested directly.

If directory listing is enabled, turn it off or ask your host to do it. Then recheck the paths you found, and repeat the check after future redeploys.

5. Rotate credentials if a sensitive file was reachable

If an exposed file may have contained an API key, database password, or other secret, assume that secret could have been copied. Remove the file, then revoke or rotate the affected credentials. Check your server or CDN logs for access, and contact your host if you need help confirming what happened.

Never store credentials in files that live in the web root. Keep secrets in your hosting platform’s protected environment-variable settings, and limit access to the people and services that need them.

Weak approach ❌	Strong approach ✅
Leave site-backup.zip beside public website files	Store backups outside the web root in protected storage
Keep .env.old “just in case”	Remove it from public folders and keep secrets in protected settings
Depend on robots.txt to hide a database dump	Block public access and store the dump privately
Assume no one found the file because analytics are quiet	Review server or CDN access logs
Delete a leaked key file but keep using the same key	Revoke and replace potentially exposed credentials

Frequently asked questions

Does turning off directory listing secure my backup files?

No. It stops the server from displaying a folder’s contents, but someone may still reach a file through its direct URL. Remove public backups or block access to them.

Is robots.txt enough to hide .env or .sql files?

No. robots.txt does not prevent people from requesting a URL. Keep sensitive files outside the web root and use proper access controls.

What should I do if I find a database backup online?

Remove or block public access immediately. Do not open or share the file. If it may contain credentials, rotate them. If it may contain personal information, contact your hosting provider and follow your applicable incident-response requirements.

Can AI-built websites have this problem too?

Yes. The risk comes from where files are stored and how the server serves them, not from the tool used to build the site. Fast experiments, repeated exports, and manual deployment can leave old files behind on any platform.

Make your next check

Run the free Smart Analytics Vulnerability Check. Choose Vulnerability Check to scan for exposed files and leaked credentials. The check is free, with no login or email required, and full findings are kept private in a downloadable PDF. It checks publicly visible signals and known file paths; it is not a full server penetration test.

You can also run the free SEO and AEO analysis to review search visibility. All Smart Analytics tools are completely free, with no paywall. Find the Meta Tag Generator, Schema Markup Generator, Robots.txt Generator, llms.txt Generator, and Search Console Regex Library on the Free Tools page. Remember, robots.txt helps guide crawlers, but it does not secure files.

Sources

• OWASP Web Security Testing Guide: Review Old Backup and Unreferenced Files
• MITRE CWE-530: Exposure of Backup File to an Unauthorized Control Sphere