Hide sensitive files in WordPress: backups, logs and wp-config copies
To hide sensitive files in WordPress, make the server answer a request for a wp-config backup, a debug log, a database dump or an .env file with a 404 instead of the file. BetterShield does that with one fix, Private file protection, which writes a single marked block into your .htaccess file. This guide covers what it hides, which servers it works on, what it can break, and how to check it from outside.
The fix belongs with the other server-level changes in WordPress hardening, which covers all thirty. This post goes deeper on the one about files, and it pairs with WordPress uploads folder security, which handles the folder where visitors’ files land.
Quick summary
- Private file protection answers requests for wp-config.php copies, log files, database dumps, editor swap files, version control and environment files, and server files with a 404, in any folder.
- It writes one marked block at the end of .htaccess, so it needs Apache, or LiteSpeed’s paid edition. On nginx, IIS and OpenLiteSpeed the row says Not available here.
- It is under What the site reveals on BetterShield › Protection › Hardening, it starts off, and Preview the change shows what it would do before anything is written.
- It hides files and deletes nothing. Delete the ones you do not need as well: hidden is good, gone is better.
- Undo never expires: turn the switch off and BetterShield removes exactly its own block.
Why these files matter
Some files say too much when they are fetched by address. A copy of wp-config.php saved as wp-config.php.bak is often served as plain text, because the server no longer sees a .php ending. A debug log can hold paths and error details. A database dump holds your content. A .git folder or an .env file can expose how the site is built and which settings it uses.
None of these files are part of how your site runs. They are leftovers: a backup made before an edit, a log left on after a fix, a dump kept for a migration. The risk is not that anyone attacks the file. It is that anyone who guesses the name can read it.
Wikipedia’s entry on .htaccess describes the file this fix writes to: a per-folder configuration file that Apache and compatible servers read on each request.
What it hides
Where the server reads .htaccess, requests for the following answer 404, in any folder:
| What | For example |
|---|---|
| Copies and backups of wp-config.php | wp-config.php.bak, wp-config.php~, wp-config.old, wp-config.zip |
| Log files | debug.log, anything ending .log, error_log |
| Database dumps | files ending .sql, or .sql packed as .gz, .zip, .bz2, .xz, .7z, .tgz, .tar, .tar.gz or .rar |
| Editor swap files | .swp, .swo and similar |
| Files every WordPress install ships | readme.html, license.txt, wp-config-sample.php |
| Version control and environment files | .git, .svn, .hg, .env |
| Server files | .htaccess and .htpasswd, and copies of them |
A few details are worth knowing:
- The wp-config backup rule applies only at the top of the WordPress folder or the site’s home folder.
- The answer is 404, not 403, whether or not the file exists, so a refusal does not confirm that the file is there.
- wp-config.php itself is not on the list. Requested from a browser it runs and shows nothing, so it needs no rule.
- The fix does not cover leftover tools such as an installer script or a database manager. The audit reports those separately, as A leftover setup or database tool is publicly reachable.
Which servers it works on
The fix writes to .htaccess, so it depends on the server reading that file.
| Your site | What the row shows |
|---|---|
| Apache | Available. |
| LiteSpeed | Available, with a note that LiteSpeed’s paid edition reads these rules and the free OpenLiteSpeed skips them, so whether they are enforced could not be confirmed. |
| OpenLiteSpeed | Not available here: your host can set the same protection in the server configuration. |
| nginx or IIS | Not available here: the server does not read .htaccess files. The same rules can be set in the server configuration; your host can add them. |
| A server BetterShield does not recognize | Available, with a note that the rules will be written but BetterShield could not confirm they are enforced. |
If another plugin already keeps rules in .htaccess, the row names it. BetterShield’s block never touches theirs. If both refuse the same request, the earlier rule answers. On nginx, IIS or OpenLiteSpeed, ask your host for equivalent rules; a fix that cannot work on your server cannot be switched on, so you never get a switch that reads on and does nothing. See Server compatibility. One fix needs no server rules at all: refusing cloud-metadata requests writes no files and works on any web server.
Set it up
- Open BetterShield › Protection › Hardening and find Private file protection under What the site reveals.
- Press Preview the change. It lists what applying would do and changes nothing.
- Turn the switch on. The row shows On since and Undo never expires.
The fix has no options, and Monitor first cannot watch it in advance: its panel points you back to the preview. From WP-CLI, wp bettershield harden sensitive_files --user=admin applies it, and adding --undo reverses it.
An AI assistant cannot apply or remove it. It writes to .htaccess, so it stays your own switch.
Applying is refused, with nothing written, when .htaccess is not writable, or when the site address and WordPress address point somewhere other than where the files are.
What it can break, and how to undo
- Files you publish on purpose with these names. A .log or .sql file meant for download, or a readme.html you link to, answers 404 too. Rename it.
- Tools that read readme.html or license.txt. They stop getting them, which is the point.
- A server that refuses the rules. If pages stop loading right after you apply it, your host likely does not allow these rules in .htaccess. Run
wp bettershield harden sensitive_files --undo --user=admin, or delete the block over SFTP or your host’s file manager, then turn the switch off.
To undo, turn the switch off. It removes exactly its block, and if BetterShield created .htaccess and nothing else was added, the file goes too. With Ask for my password before an action that removes a protection on, undo asks for your password.
If anyone edited inside the block, undo leaves it alone and the row says the last undo did not complete. Keep whatever was added, delete the block by hand, then turn the switch off again.
The block stays in .htaccess, and keeps working, while safe mode is on and while BetterShield is deactivated. Deleting BetterShield keeps it too, unless you chose to remove its records under When this plugin is deleted on Settings › General.
Check it is working
- From outside. In a private window, open /readme.html and /license.txt on your site. You get a 404 instead of the file. This is the check that matters, because the row itself says only that this fix “has no effect a page view can check, so it is reported from your settings.”
- The activity log. “Hardening applied”, or “Hardening could not be applied” if it was refused. See Activity log.
- Findings. Files that should be private can be downloaded from this site (Critical) comes from a weekly check that asks your site for a few such files (wp-config backups, .env, .git/config, debug.log, common database dump names) and reports only what really came back. With the rules working those requests get 404, so the finding clears after the next weekly check.
The files are still there, though. In the finding’s words, removing one is yours to do, and it is worth keeping a copy somewhere outside the web root first.
On multisite
Every site on a network shares one .htaccess. Apply the fix from the network’s main site and it protects all of them. On any other site the row reads Not available here.
Recommended settings
We recommend turning it on for any site on Apache, or LiteSpeed’s paid edition, and then deleting any such file you do not need. Hidden is good, gone is better. On nginx, IIS or OpenLiteSpeed, ask your host for equivalent rules in the server configuration. On a network, apply it once, from the main site. The same page also gives away which WordPress you run, and our guide to hiding the WordPress version covers that.
Frequently asked questions
Does this delete my backups and logs?
No. It hides files and deletes nothing. A hidden file is still on the server, so remove the ones you no longer need, after keeping a copy somewhere outside the web root if you want one.
Why does it answer 404 and not 403?
A 403 would tell a visitor the file exists and is being refused. A 404 is the same answer whether or not the file exists, so a request for a guessed name learns nothing.
Is wp-config.php itself protected?
It does not need a rule. Requested from a browser, wp-config.php runs and shows nothing. The risk is in copies such as wp-config.php.bak, which the server may serve as text, and those are on the list.
My site runs on nginx. What can I do?
The row shows Not available here, because nginx does not read .htaccess files. Your host can add the same rules to the server configuration.
Will it work with another security plugin that edits .htaccess?
BetterShield keeps its rules in its own marked block and never touches anyone else’s. The row names the other plugin, and if both refuse the same request, the earlier rule answers.
Conclusion
One switch closes the quiet gap that backups, logs and dumps leave open: the server answers 404 for all of them, nothing is deleted, and the undo never expires. Preview it first, turn it on, then check /readme.html in a private window and clear out the files you no longer need.
BetterShield is free on WordPress.org. The docs cover the fix in full: Hide sensitive files and Hardening.