Site Hardening · Part 5
The door nobody installs
Most hardening advice is about software: which plugins to trust, which versions to run. This part is about something quieter — the files that end up on a web server without anyone deciding they should be there.
A web server has one job: hand files to whoever asks for them. Anything in a public folder is one request away from anyone who knows, or guesses, its name. So every file on the server should be one you would be comfortable handing to a stranger. Most servers fail that test, and the files that fail it are rarely the ones people worry about.
The file that opened this case
From the case file. The sites in this hosting account were built in a desktop publishing program. When it publishes a site, it offers to store the project file on the server as a backup. That is a sensible-sounding feature, and the owner used it.
The project file contains the publish settings: the server address, the file-transfer username, and the password, disguised but reversible. The login was scoped to the top of the hosting account — every site, not one — and it used plain, unencrypted file transfer.
So the backup was the credential. Nobody had to break anything. The best-supported explanation for how the intruders got in is that they read a file the owner’s own software had been asked to leave there. That remains an inference rather than a proven fact, and the investigation says so — but it is the only explanation that fits everything that followed.
The lesson generalises far beyond one program. Your software leaves things on your server, and some of those things know your secrets.
What to look for
Go through your web folders looking for anything that isn’t part of the working site. These are the usual suspects:
- Project and publish files from site builders, design tools and editors — anything that stores where and how to upload.
- Backups and archives — .zip, .tar, .gz, .bak, and full-site backups written by plugins.
- Database exports — any .sql file, which is your whole site’s content plus your users table.
- Old copies of pages — index-old.php, wp-config.php.bak, site-backup-2021. Old copies of configuration files still hold real passwords.
- Editor and sync settings — the files code editors and upload tools use to remember a connection.
- Version control and environment files — a .git folder or a .env file in a public folder can expose your entire history or every key the site uses.
- Diagnostic and test scripts — the file you uploaded once to check a PHP setting or test a fix, and never removed.
- Log files — error logs written into public folders can reveal file paths, usernames and the software you run.
The test for each file is simple: what does it know, and who can ask for it?
How to find them
List everything, not just what you recognise. Use your file-transfer program or the host’s file manager to list every file in the public folders, including hidden ones — names starting with a dot are hidden by default in most tools. On a large site, a full listing exported to a spreadsheet is easier to read than clicking through folders.
Sort by type. Anything that isn’t a page, an image, a style sheet, a script the site actually loads, or a known part of WordPress deserves a question.
Sort by date. Files that don’t match the age of the site around them — much older, or much newer — are worth opening.
Then try to download them. Put the file’s address into a browser. If it downloads or displays, anyone can do the same. If it’s refused, check that the refusal is deliberate and not an accident of today’s configuration.
Found while writing this
This section wasn’t planned.
From the case file. While this article was being written, a check of the author’s own site turned up a small script in the top folder of the web server. It had been uploaded during the hardening after the compromise, for one job: print the server’s full folder path, which you need when writing protective rules that point at specific folders. The job was done. The file stayed.
Anyone who requested it got an answer. The path it printed included the hosting account’s username — half of the login that reaches every site in the account. And the file’s name was listed in the site’s own robots.txt, asking search engines to stay away from it. That line kept honest crawlers out and told everyone else exactly which file was worth requesting.
It was downloaded for the record and deleted from the server the same night.
Less than an hour later, the same kind of check found a second one: the owner’s own page-metadata tool, left at the top of the site where anyone could open it — a working form, with no password in front of it. It had been uploaded to generate files and never taken back down. It now lives only on his own computer, and the files it produces go up over SFTP.
Nobody had to break anything to find either one — which is the whole point of this article. The files that give you away are usually ones you put there yourself, for a good reason, and forgot.
Where these files belong
Not deleted — most of these files are genuinely useful. Just not on the web server.
Project files live on the computer you build from. Backups go to storage the web server can’t reach — your own drive, or a service that pulls copies off the server rather than leaving them on it. Database exports get made, downloaded and removed in the same sitting.
From the case file. After the compromise, the owner took a complete copy of the old server’s files and kept it — on his own drives, not the server. That copy became the primary evidence for the whole investigation. It is exactly as valuable as a backup on the server would have been, and it can’t be read by anyone who gets into the hosting account.
The cleanup leaves its own
One more category, easy to miss: files you create while fixing things.
The safe way to deal with suspicious files during a cleanup is to rename them rather than delete them, so a mistake can be undone — Part 10 of the investigation series explains why. But a renamed payload is still sitting in a public folder, and renamed to a plain-text extension it will happily show its code to anyone who asks. The same goes for test files, notes and scripts written in a hurry during the fight.
Once you are sure what they are, move them off the server into your own evidence folder.
And never list sensitive files in robots.txt to keep crawlers away from them. robots.txt is public. It can’t protect a file — it can only advertise that the file exists. Part 7 returns to that.
Make it a habit
This isn’t a one-time sweep. Software keeps writing files, and people keep uploading things to test them. Put a recurring reminder on the calendar: list the web folders, look for anything that isn’t the site, and move it off. Ten minutes, a few times a year, against the one failure in this case that no security plugin would ever have caught.
A file that shouldn’t be on the server is usually found only after someone else has read it. A recovery review walks the web folders and asks what each one knows.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: One Hosting Account, One Target: The Dormant Site Problem
Next: File Permissions That Actually Stop Writes
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.