Keeping backups is good practice. Keeping them inside a website’s public directory is not.
A public directory — often called the web root, public_html, www or htdocs — contains the files that a web server is allowed to make available online. Anything placed there should be treated as potentially reachable from the internet, even when there is no link to it on the website.
That distinction is easy to miss. A file called website-old.zip, a copied folder named backup, or a complete clone at /old-site/ may feel hidden because it does not appear in the navigation. In reality, search engines, automated scanners and attackers can discover files and folders by guessing common names, following old links, reading directory listings, inspecting logs or trying known paths.
The safest rule is simple: the live website should contain only the files it needs to operate. Backups and retired copies belong in separate, access-controlled storage outside the public directory.
What commonly gets left online?
This problem is not limited to formal backups. A public directory can gradually collect:
- compressed archives such as
.zip,.tar,.tar.gzand.sql.gzfiles; - copied files with names such as
.bak,.old,.orig,copyor a date added to them; - database exports, spreadsheets and customer-data downloads;
- old versions of configuration or environment files;
- complete clones created before a redesign, migration or major update;
- abandoned WordPress, Joomla, Drupal or other CMS installations;
- development, test and staging copies under folders or subdomains;
- temporary files created by editors, deployment tools or hosting control panels;
- source-control folders, deployment packages and server logs.
Some of these files are placed online for a few minutes and then forgotten. Others survive several changes of developer or hosting provider because nobody is sure whether they can be deleted.
Why an unlinked file can still be public
A web server does not normally ask whether a file appears in a menu. It receives a path and, if its configuration allows it, returns the matching file.
This means example.com/backup/site.zip can be downloadable even when no normal visitor knows that address. File and folder names are often predictable, and automated tools can test thousands of likely paths very quickly. Blocking search-engine indexing or omitting a link does not create access control. Even a password in the filename is only a guessable secret.
Server rules that block selected extensions can provide an extra layer of protection, but they should not be the reason a sensitive backup is considered safe. Rules can be removed during a migration, applied to one folder but not another, or behave differently after a server change. If a file does not need to be publicly served, it should not be in the public directory.
The security risks
Source code and credentials can be disclosed
A live server usually processes application files before sending a response. A backup copy with a different extension may instead be downloaded as plain text. It can reveal database credentials, API keys, email settings, internal paths, administrator addresses and details of how the application works.
A single archive can be worse because it may contain the whole site: source code, configuration, uploaded documents, log files and a database export in one convenient download.
Old website clones remain attackable
A clone is not harmless simply because the business no longer uses it. If it is reachable online, its login pages, plugins, themes, libraries and scripts may still execute.
Retired copies are especially risky because they often stop receiving security updates. An attacker can exploit an old plugin or application even when the current website is fully patched. Depending on the hosting setup, that foothold may allow them to modify the live site, upload malicious files, read data or use the account to send spam and phishing messages.
Personal and commercially sensitive data may be exposed
Database dumps and uploaded-file backups can contain names, contact details, order history, account information, private documents and password hashes. Logs may contain email addresses, IP addresses, reset links or session information.
Exposure can create contractual, regulatory and reputational consequences as well as a technical incident. Backups should therefore be protected according to the sensitivity of the data inside them, not treated as ordinary spare files.
Attackers gain a map of the website
Even when an old file contains no working password, it can reveal software versions, hidden routes, database structure, naming conventions and code that is not visible from the live site. That information makes further attacks easier and more targeted.
Storage, performance and recovery become harder to manage
Large archives and duplicate sites consume hosting space and may push an account towards its quota. They also create noise during migrations, malware scans and incident response. When several copies exist, nobody can be certain which one is authoritative or safe to restore.
A backup is not the same as an old copy
A reliable backup is created deliberately, stored securely, monitored and tested. It has a known date, scope, owner and retention period. The business knows how to restore it.
A copied folder inside public_html is usually just another live set of files. It may be incomplete, publicly accessible, infected at the same time as the main site or lost when the hosting account fails. Calling it a backup does not make it a dependable recovery plan.
Likewise, keeping an obsolete clone “just in case” is rarely useful unless its database, uploaded files and configuration are preserved consistently and somebody has verified that it can be restored. Source code may be better retained in private version control, while database and uploaded content are handled by a proper backup system.
Where website backups should be stored
The right arrangement depends on the website and the importance of its data, but a sound backup process should include the following controls.
Keep backups outside the web root
Use storage that the public web server cannot serve directly. This might be a protected backup area provided by the host, a separate server, an encrypted cloud-backup service or offline media. A folder beside the public directory can be suitable only when hosting permissions and access controls are correctly configured; a folder inside it is not.
Separate backups from the live hosting account
At least one recoverable copy should not depend on the same account, server or credentials as the website. If an attacker compromises the hosting control panel, backups stored under that same login may also be deleted or altered.
The National Cyber Security Centre describes the widely used 3-2-1 approach: keep at least three copies, on two devices or storage types, with one copy off-site. It also recommends keeping at least one backup offline or otherwise digitally disconnected so an incident cannot affect every copy at once.
Encrypt and restrict access
Backups can contain more information than the public website, so encrypt them in storage and during transfer where the service supports it. Limit access to the people and systems that genuinely need it, protect administrative accounts with multi-factor authentication, and keep backup credentials separate from everyday website credentials.
Use retention rules instead of indefinite accumulation
Decide how many daily, weekly and monthly copies are required and remove older backups according to an agreed schedule. The correct period depends on how quickly a problem might be noticed, recovery needs, contracts and legal obligations. Indefinite retention increases cost, uncertainty and the amount of data exposed if the backup store is compromised.
Make backups immutable or offline where practical
Immutable storage prevents a backup from being changed or deleted during its protected period. Offline or logically disconnected copies provide additional protection against ransomware, compromised accounts and accidental deletion.
Test restoration
A successful “backup completed” message proves only that a process ran. Test that files and databases can be restored, that the restored website starts correctly, and that the test itself takes place in a private environment. Record the result and resolve failures before an emergency.
How to audit what is publicly exposed now
Do not begin by deleting every unfamiliar file. First establish what exists, what is reachable and what the live website depends on.
1. Confirm the boundary of the public directory
Ask the hosting provider or website administrator to identify every web-accessible location, including the main document root, subdomains, additional domains, upload directories and any staging sites. Hosting accounts sometimes serve more than one folder, so checking only public_html may miss an exposed clone elsewhere.
2. Create an inventory before making changes
Record folders and files with their full path, size, last-modified date and owner where available. Pay particular attention to:
- archive and database-export extensions;
- unusually large files;
- names containing
backup,bak,old,copy,clone,archive,temp,test,staging,devor dates; - multiple application entry points or administration panels;
- old CMS installations and duplicate configuration files;
- hidden files, logs and source-control metadata;
- folders that have not changed alongside the live application.
Do not assume a recent modified date means a file is required. Automated backup, malware or deployment processes can update an otherwise obsolete file.
3. Check whether suspected items are reachable
Have a competent administrator test from outside the hosting account whether each suspected path returns a file, directory listing, login page or other response. Review web-server and content-delivery logs for past requests to those paths.
Avoid opening unknown scripts through a browser merely to see what they do: that may execute vulnerable or malicious code. Inspection should be carried out safely from the hosting or server side.
4. Identify what the live website actually uses
Compare the inventory with the current deployment records, application configuration and database. Confirm the active document root and look for scheduled tasks, redirects, symbolic links or integrations that refer to old folders.
For each item, classify it as:
- required and public — an asset the live site genuinely serves;
- required but not public — data, configuration, logs or backups that should be moved and protected;
- obsolete — an old copy with no operational or retention need;
- unknown — something that requires investigation before any change.
5. Look inside archives and clones safely
An archive’s filename does not reveal whether it contains personal data, credentials or malware. Examine it in an isolated, non-public environment. Establish its age, contents, business purpose and whether a cleaner, verified backup already exists elsewhere.
For old applications, record the software, version, database connection and data held. If a clone must be retained for historical or legal reasons, preserve it as an encrypted archive in restricted storage rather than as a working public website.
6. Quarantine before permanent deletion
Move confirmed obsolete items out of the public directory into a restricted quarantine location. Do not simply rename the folder within the web root; the new name may still be reachable.
Monitor the live website, forms, scheduled tasks and integrations for an agreed period. Once the business owner and technical administrator are satisfied that nothing depends on the items — and any legitimate retention need is covered by a verified backup — delete them securely from the quarantine area in line with the retention policy.
7. Treat evidence of access as a possible incident
If logs show that an archive, database export, configuration file or obsolete application was accessed by an unknown party, removal alone may not be enough. Preserve the relevant logs and seek incident-response advice. Credentials and keys contained in the exposed material may need to be changed, affected systems checked, and data-protection or contractual obligations assessed.
Prevent the problem returning
Cleanup is only effective if normal working practices also change.
- Configure automated backups to write directly to protected storage outside the public directory.
- Deploy from private version control or a controlled release package rather than copying the live site into another public folder.
- Use access-controlled staging environments that receive the same security updates as production, and remove them when the project ends.
- Give every temporary environment an owner and expiry date.
- Block unnecessary backup, archive and temporary-file extensions at the server as an additional safeguard.
- Include public-directory checks in routine maintenance and before or after every migration.
- Monitor storage growth and unexpected new files.
- Keep a short backup register covering locations, frequency, retention, encryption, access owners and the latest restore test.
- Make secure removal of old copies part of the handover when changing developer, agency or host.
A simple rule for every file
For anything stored with the live website, ask: does the public website need to serve or execute this file?
If the answer is no, it should normally be outside the public directory. If it is a backup, store it through a managed, access-controlled backup process. If it is an obsolete clone, preserve only what there is a genuine reason to retain, then remove the working public copy.
Good backups reduce risk. Forgotten copies increase it. The difference is not merely the file’s name, but where it is stored, who can access it, how it is maintained and whether it can be restored safely.
Useful security guidance
- Review old backup and unreferenced files for sensitive information — OWASP Web Security Testing Guide
- File Upload Cheat Sheet: file storage location — OWASP Cheat Sheet Series
- Offline backups in an online world — UK National Cyber Security Centre
- Backing up your data — UK National Cyber Security Centre
W.E.B.S Ltd can help audit a hosting account for old website copies, exposed archives and unnecessary public files, then put a safer backup and retention process in place. If the review finds evidence that sensitive material may already have been accessed, specialist incident-response and legal advice may also be appropriate.