Stray Files in Your Web Folder That Anyone Can Download

Everything in your website's public folder can be downloaded by anyone who guesses or finds its name. That includes files you never meant to publish: a copy of your server code saved as a .txt file, a list of email sign-ups, a test export. These stray files in your web folder are one of the most common and most overlooked security leaks on small sites.

How stray files end up public

They almost always arrive innocently:

• Backup copies made before an edit: index.html.bak, app.js.old, file (2).html.
• Code saved for reference: app_new.txt, tools_new.txt.
• Data files: waitlist.txt, exports, CSVs.
• Test outputs from tools you ran in the same folder.
• Old copies of pages left in a second folder that's also public.

Search engines can find them through links, directory listings or guessing, and AI crawlers read them too.

Why stray files are a real risk

Code copies reveal how your site works

A copy of your server code shows your routes, checks and sometimes settings. That's exactly what someone looking for weaknesses wants.

Data files can breach privacy law

A public file of names and emails is a personal-data leak under GDPR, even if nobody has downloaded it yet.

Old page copies confuse search engines

An outdated copy of a page can carry wrong prices, old wording or a canonical tag pointing to a development address. We found an old pricing page still reachable at a second address, telling Google its real home was a dev subdomain.

How to find stray files in your web folder

1. List non-page files in the public folder. Look for .txt, .md, .json, .csv, .bak, .old and anything with "(2)", "copy", "new", "test" or a string of digits in the name.
2. Check whether each one is reachable. Request it in a browser or with curl -s -o /dev/null -w "%{http_code}". A 200 means it's public.
3. Check for data without dumping it. Count lines or @ symbols instead of opening a file on screen, so you don't expose personal data while checking.
4. Look for duplicate page folders that your server can also serve, and check their canonical tags.

How to remove them safely

Move, don't delete

Move stray files to a private folder outside the web root. If something turns out to be needed, you can put it straight back.

Check nothing links to them first

Search your pages and scripts for each file name. If a live page links to a file, it may be part of the site; find out before moving it. Files that are only mentioned by each other are usually a leftover set.

Confirm it's gone

After moving, the address should return 404.

Stopping stray files coming back

• Keep backups outside the web folder. Make a tmp or backups folder that your server doesn't serve.
• Block common backup extensions at the server. An nginx rule can deny .bak, .old, .orig, .swp and similar. Remember it won't catch names like app_new.txt or 11111combined-audit.js.
• Review the folder after each deploy. A quick list of recently changed files catches leftovers early.

Summary

Anything in your public folder is public. List the non-page files, check which respond with 200, move anything that isn't meant for visitors to a private folder, and confirm each one now returns 404. For a wider check of what your site exposes, run the security audit.

Frequently asked questions

Why are backup and test files in a public web folder a security risk?

Everything in a website's public folder can be downloaded by anyone who guesses or finds its name, and search engines and AI crawlers can find such files through links, directory listings or guessing. A copy of server code saved as a text file reveals routes, checks and sometimes settings, which is exactly what someone looking for weaknesses wants. A public file of names and email addresses is a personal-data leak under GDPR, even if nobody has downloaded it yet. Old copies of pages can also confuse search engines by carrying wrong prices, outdated wording or a canonical tag pointing to a development address.

How do you find stray files in your web folder?

Start by listing the non-page files in the public folder. Look for extensions such as .txt, .md, .json, .csv, .bak and .old, and for names containing (2), copy, new, test or a string of digits. Next, check whether each one is reachable by requesting it in a browser or with curl and reading the HTTP status code; a 200 means it is public. To check for personal data without exposing it, count lines or @ symbols rather than opening the file on screen. Finally, look for duplicate page folders that your server can also serve, and check the canonical tags on those copies.

What is the safest way to remove stray files from a web server?

Move stray files rather than deleting them. Put them in a private folder outside the web root, so if something turns out to be needed you can put it straight back. Before moving anything, search your pages and scripts for each file name; if a live page links to a file it may be part of the site, so find out first. Files that are only mentioned by each other are usually a leftover set. After moving, confirm the address returns 404. To stop files coming back, keep backups outside the web folder, block common backup extensions such as .bak, .old, .orig and .swp at the server, and review the folder after each deploy.