I’m looking to provide some Caddy examples for the WordPress support article Hardening WordPress. that presently only has a couple of Apache examples. More details in the next post.
A second layer of protection can be added where scripts are generally not intended to be accessed by any user. One way to do that is to block those scripts using mod_rewrite in the .htaccess file. Note: to ensure the code below is not overwritten by WordPress, place it outside the # BEGIN WordPress and # END WordPress tags in the .htaccess file. WordPress can overwrite anything between these tags.
Note that this won’t work well on Multisite, as RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] would prevent the ms-files.php file from generating images. Omitting that line will allow the code to work, but offers less security.
You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder.
Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).
If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it:
<files wp-config.php>
order allow,deny
deny from all
</files>
I’ll see if I can come up with some Caddy equivalent code in the next post.
Initial observations on the Apache code for part 1 Securing wp-includes:
In a standard WP install, paths wp-admin/includes/ and wp-includes/ exist, but paths wp-includes/js/tinymce/langs/ and wp-includes/theme-compat/ do not.
When I look up RewriteRule and RewriteFlags, I think these lines…
…
For a Caddy web server, add the wp-config.php path to the named matcher set described under Securing wp-includes. This will prevent access to wp-config.php in the webroot,
path /wp-config.php
@francislavoie okay to proceed to a WP doc update request? @Whitestrake please let me know if I’ve missed something in the translation of the Apache code in post #2, and I’ll submit a change request in the WP doc issues tracker.
It looks like they’re very specific about targeting those three things in ./wp-includes/. I wonder if that is because there are other files in that directory that are meant to be accessible.
On its face I can’t think of any and assume that denying the entirety of those directories would be A-OK; but if that gets knocked back for some good reason, you might want to be ready to refactor to deny those paths specifically instead.
I’m confident that the proposed Caddy code will work as I’ve been running with a not dissimilar named matcher set on my own and several customer WP sites for the last couple of years without incident.