A direct request to wp-config.phpmay reveal no output because PHP executes it, yet a forgotten copy such as wp-config.php.bakcan be downloaded as plain text. Protection must cover the real file, stray copies and filesystem access.
Prefer placing the configuration outside the public directory when the layout supports it, keep restrictive permissions and add a server denial as defense in depth.
What it means
wp-config.phpcontains database settings, salts and environment-specific configuration. Apache can deny HTTP requests for the file while PHP still includes it locally during the WordPress bootstrap.
Apache 2.4 uses Require all denied; older compatibility syntax may differ. The rule must match the server version and the actual file location.
A realistic WordPress example
The main configuration executes normally on a direct request, but an editor-created .bakcopy downloads and exposes credentials. A rule covering only the exact production filename misses the larger problem.
The administrator removes the backup from the web root, rotates exposed secrets, tightens permissions and verifies a server-level denial for the real file.
Why it matters and when to use it
Preventing direct delivery protects against server misconfiguration and accidental source exposure. It complements, rather than replaces, correct file placement, secret management and operating-system permissions.
Use the rule only on a server that reads this .htaccess. Nginx and managed platforms require their own access-control mechanism.
A straightforward route for beginners
- Locate the active
wp-config.phpand search the public tree for copies or editor backups. - Remove unnecessary copies and rotate any secret that may have been exposed.
- Record the current file owner and permissions.
- Back up
.htaccess, then add the server-version-appropriate denial outside WordPress markers. - Request the exact filename and likely backup suffixes from a signed-out client.
- Confirm that the front end, admin and scheduled requests still bootstrap normally.
The advanced route
Verify the response at the origin as well as through a CDN, and distinguish a true 403 from a blank 200. Consider placing wp-config.phpone directory above the web root where WordPress and the hosting layout support that standard location.
Enforce restrictive filesystem permissions and prevent deployment tools from emitting temporary or backup files under public paths. Web denial cannot protect local users with excessive read access.
Risks, common mistakes, backup, and rollback
Rules copied for the wrong Apache version can return 500, while a pattern that is too broad may block required files. A CDN-generated denial can also hide an origin that still serves the file.
Keep an external copy of .htaccessand test WordPress immediately after the change. If credentials were downloadable, restoring access controls is not enough; rotate them.
How AIOWS helps:
AIOWS Htaccess Editor
AIOWS Htaccess Editor can maintain a supported Apache access rule in the active file and keep it visible for review with other custom directives.
Back up the file first, use syntax valid for the host and test from an unauthenticated client. Also inspect the public directory for configuration copies that no rule should leave behind.
The editor cannot relocate secrets, rotate credentials or change operating-system permissions. Complete those tasks through the hosting and deployment controls responsible for the files.
Related AIOWS articles
- How to Disable Directory Listing in WordPress with .htaccess
- How to Block XML-RPC in WordPress with .htaccess
- WordPress Security Headers with .htaccess: HSTS, CSP and More
Conclusion and recommended route
Remove configuration copies from public storage, restrict the real file and verify an origin-level web denial without breaking WordPress. If any secret was exposed, rotate it promptly.
