Block Access to Sensitive Files writes .htaccess rules that deny public access to configuration files, version-control directories, backups, logs, dotfiles, and other files that should never be served to the internet but often end up in the document root by accident.

What this feature does

WordPress sites accumulate files that aren’t supposed to be public: backups left over from migrations, .env files copied during deploys, .git directories deployed accidentally, log files generated by plugins, and so on. Each of these can leak credentials, source code, or sensitive configuration to anyone who guesses the URL. Automated scanners constantly probe for them.

This setting writes a comprehensive .htaccess deny block that blocks every common pattern in one go.

What gets blocked

Pattern Why it’s sensitive
.ht* .htaccess, .htpasswd, and any other dotfile starting with .ht.
*.env Environment files containing API keys, database credentials, etc.
wp-config.php, config.php, configuration.php WordPress and other CMS config files. PHP normally renders these so they’re not exposed, but a misconfigured server can serve them as plain text.
composer.json, composer.lock, package.json, package-lock.json, yarn.lock Dependency manifests. Reveal exact versions of libraries, useful for targeting known CVEs.
.git*, .svn, .hg Version-control directories. Can leak full source-code history if served.
README.md, CHANGELOG.md (and .txt versions) Often reveal exact versions of installed software.
*.ini, *.bak, *.backup, *.old, *.orig, *.tmp, *.log, *.sql Configuration files, backup copies, database dumps, log files. Common artefacts of failed migrations.
Files ending in ~ Editor backup files (e.g. wp-config.php~), often left behind by command-line editing on the server.
Defence against accidental exposure

You probably don’t have a .git directory or a backup.sql in your document root right now. The point is to make sure that if either ever ends up there (a botched deploy, a manual edit, a plugin’s temp file), it’s blocked from the start. Apply this once and stop worrying about it.

How to enable it

  1. Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
  2. Toggle Block access to sensitive files on. Save settings. AdminEase writes the deny block to .htaccess immediately.
  3. Verify. Test with curl -I https://yoursite.com/wp-config.php and curl -I https://yoursite.com/.env. Both should return HTTP/1.1 403 Forbidden.

Settings reference

Setting What it does Default
Block access to sensitive files Writes a managed .htaccess block that denies the patterns listed above. Off

What happens behind the scenes

.htaccess deny rules + mod_rewrite

AdminEase writes a managed .htaccess block (between BEGIN AdminEase and END AdminEase markers) containing <FilesMatch> blocks for the file-name patterns and mod_rewrite rules to forbid .git, .svn, and .hg directory access. Anything outside the marker block is preserved untouched.

On Apache, the rules return 403 Forbidden directly without invoking PHP, which makes the block essentially free in terms of server load.

Troubleshooting

I have a legitimate .txt file that’s being blocked

The block targets specific filename patterns like README.txt and CHANGELOG.txt. Other .txt files (e.g. robots.txt) are not blocked. If a specific file is being blocked unexpectedly, rename it or use the adminease_block_access_sensitive_files_code filter to customise the rules from a small mu-plugin.

I’m on Nginx and the rules don’t apply

Nginx doesn’t read .htaccess. Ask your host to add equivalent location blocks to your Nginx config that deny the same patterns. AdminEase still writes the file in case it’s ever read by another server.

My deployment script puts .git in the document root

Don’t do that. Even with this block, the directory existing on the server is a small risk: file permissions might allow other tenants on shared hosting to read it. Configure your deployment to keep .git outside the web root entirely.

A backup plugin can’t write its log file

Unlikely. The block prevents public HTTP access, not file writes. PHP can still create and read these files normally; only browsers and curl get the 403. If a plugin actually breaks, file an issue with the plugin author so they can use a non-blocked extension or path.