Look through the public web folder for anything that is not part of the live site: old folders, zip files, database exports and renamed configuration files. Keep what you need somewhere private, delete the rest, and change exposed passwords.

What gets left behind

Every website lives in a folder on a server, and anything in its public part can be requested by anyone, whether a page links to it or not.

Over the years, that folder collects things never meant to be public.

A copy of the previous site in a folder called old. A zip of everything, made before an update. A database export from a move between hosts.

Nobody linked to them, so nobody thinks of them as part of the website. But unlinked is not the same as private.

How they are found

No clever guessing is needed. Automated tools request common names on site after site, all day: backup.zip, site.zip, old, test, and configuration files with an extra ending added.

A request for a file that is not there costs them nothing. A request that finds one returns the whole file.

If a folder has no page of its own and the server allows directory listing, asking for the folder returns a list of everything in it, which removes even the guessing.

What to look for

The third is the most dangerous for its size. A file ending in .php runs as a program, so its passwords never reach a browser; with most other endings it is sent as plain text, passwords included.

Why a full copy is worse than it looks

A zip of the site holds more than pages: the configuration file with the database password, every uploaded file, and often a database export with customers' names, emails and phone numbers.

An old copy of the site still running in a folder is a different risk. It works, on the software it had when it was copied, with years of missed updates.

That makes it the easiest way into the hosting account, and from there into the live site beside it. Forgotten copies are a common route to the kind of hack that fills a site with spam pages.

Finding them

Open the file manager in the hosting control panel and go to the public folder, usually called public_html.

Sort by size. Archives and database exports are usually the largest files there, and they stand out at once.

Then ask what each top-level folder is for. A WordPress site is mostly three folders beginning with wp, some files, and a folder or two the host creates. Anything else needs an explanation.

Search the whole folder for endings that should never be public: .zip, .tar, .gz, .sql, .bak, .old and .orig, plus file names ending in a tilde, which some editors leave behind.

Check each subdomain's folder the same way. Old shops and test copies often live there.

A worked example

A home inspection company with three inspectors moved to a new website two years ago. It was built on the same hosting account, and the developer moved the old site into a folder called old-site.

Before switching over, the developer also zipped the old site and its database into one archive and left it in the public folder, in case anything needed checking later.

The archive held four years of entries from the old booking form: names, phone numbers, the addresses of homes being bought, and the dates of inspections.

Nobody at the company knew either was there until the account ran short of disk space this summer.

The archive was copied to the company's own backup storage and deleted from the server. The old-site folder and its database were removed, every password in the files was changed, and directory listing was turned off.

The company recorded the exposure and took advice on whether it needed reporting.

Removing them properly

Decide first whether anything is needed. Usually little is: the live site has its own backups, and a two-year-old copy of a replaced site is rarely worth keeping.

Anything worth keeping should be moved, not renamed. A file renamed from backup.zip to backup.zip.old is still downloadable. Move it above the public folder, which the server never sends to browsers, or off the server.

Delete old copies of the site entirely, along with their databases, which usually sit separately on the server. A copy that does not exist cannot be broken into.

If something sensitive was exposed

If a configuration file or database export was downloadable, assume the passwords in it are known. Change the database password, every administrator password, and any keys for payment or email services stored alongside.

Raw access logs in the control panel show which files were requested and sent. They only go back so far, so read them soon.

If the file held customers' personal information, take advice on your obligations. Depending on which privacy law covers the business, the exposure may have to be recorded, and reported if it could seriously harm the people affected.

Keeping it from happening again

Most of these files are made during work: a redesign, a move, an update. Ask whoever does the work to keep archives outside the public folder and remove test copies before calling the job finished.

Then look at the public folder twice a year. Five minutes sorting by size and date catches most of what slips through.

The counter-case

Not everything unfamiliar in the folder is a problem.

Hosts and tools put some files there for good reasons, such as a folder used when a certificate is issued, or a file verifying the site to a search engine. Ask before deleting what you do not recognise.

A small site with no database has less to leak, and a quicker check.

For any site with a database, a login or a form, though, the public folder should hold the live site and nothing else.

The check

  1. Open the public folder in the file manager.
  2. Sort by size and examine the largest files.
  3. Search for backup endings such as .zip and .sql.
  4. Ask about every folder you cannot explain.
  5. Move what you keep out of the public folder.
  6. Delete old copies and their databases.
  7. Change any passwords those files contained.

Step five is the one people skip by renaming instead. A renamed file is still sent to anyone who asks for it; only moving it or deleting it takes it off the web.

What happens when a forgotten copy becomes the way in is covered in a website hacked to sell something else.

Frequently asked questions

Can people download files nobody links to?

Yes. Anything in the public web folder can be requested by name, and automated tools request common names such as backup.zip on site after site, all day.

Why is a renamed configuration file dangerous?

A file ending in .php runs as a program, so its passwords stay hidden. With another ending, such as .bak, the server sends it as plain text.

Is an old copy of the site a risk?

Yes. It still runs on the software it had when it was copied, with years of missed updates, and it shares the hosting account with the live site.

Is renaming a backup file enough?

No. A renamed file is still in the public folder and still downloadable by anyone who requests it. Move it out of the public folder or delete it.

Where should backups be kept instead?

In the host's backup system or separate storage, or at least in a folder above the public one, which the server never sends to browsers.

What if a database export was exposed?

Assume its passwords are known and change them, read the access logs soon, and if it held customers' personal information, take advice on recording and reporting it.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Site redesigned or moved in the last few years?

Ask us to list what is sitting in your public folder. We will tell you what to keep and what to remove.

Start a Conversation