Good Practice for Securing the WordPress wp-config.php File

Without diving into the arguments for and against moving the wp-config.php file as a security precaution, if you do decide to secure the file, here’s one way of doing it that draws on an earlier suggestion about enabling PHP code to adapt to different server storage architectures.

In a separate article on adjusting PHP code to work with alternative storage schemes — including OS X Server, which stores site files in domain-specific sub-directories of an overall /Sites directory — I described the merits of one method for moving site support files to a centrally managed location. This type of method can easily be applied to the problem of moving the wp-config.php file, which is frequently recommended as one step toward making WordPress a little more secure. (See “Good Practice for Adapting PHP Code to Alternative Storage Schemes, Including OS X Server’s”.)

(I won’t go into the arguments for and against moving the wp-config.php file; the web is full of diatribes both for and against, some technically well-informed, some not so much. The aim of this article is to suggest what I believe is a worthwhile approach you might want to consider if you are interested in doing it at all.)

Three problems are frequently cited in response to the common advice to move wp-config.php:

1. if WordPress lives in a sub-directory rather than at the root level of your site, moving wp-config.php up one level does nothing to take it out of a web-accessible location,
2. if you do move wp-config.php out of a web-accessible location, you may open up new security holes as a result of any required open_basedir adjustments, and
3. some themes, plugins, etc. break if wp-config.php isn’t in the expected location.

The approach I’ll describe here addresses the first two fully and the third partially. It remains the case that if a plugin or theme specifically wants to write to your wp-config.php file, then this approach may break it. Some of the popular caching plugins, for example, jump right in and start stomping around in wp-config.php. (In my view, writing to the wp-config.php file without advance warning to the user and a clearly described work-around for doing it yourself represents a certain level of coding arrogance. It’s like a postman saying that well, he has a job to do, and if you want him to do that job and give you any mail, he’s going to need to open your front door and walk into your house unannounced — and if you don’t leave your front door unlocked all the time so he can do that, then it’s your fault if anything goes wrong with your mail delivery.)

In my view, a good balance of functionality and security can be achieved by not moving the wp-config.php file at all, but rather by chopping out nearly all of it and placing it in a different file altogether, loading it via an include() or require() from what remains of the wp-config.php. In other words, we chop out everything before the final require_once() and load it separately:

require_once( '/path/to/wp-config-contents.php' );

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

We avoid the security problems inherent in open_basedir adjustments by employing the method I described in the article on preparing PHP code for OS X and storing all wp-config-contents.php (or whatever you choose to call them) files in a carefully chosen and carefully controlled central location:

@include('path/to/map.php'); // grab our server map, if there is one, from PHP include path

if ( defined( 'SUPPORT_FILES_LOCATION' ) )
	$require_prefix = SUPPORT_FILES_LOCATION . 'example.com/site_constants/';
else
	$require_prefix = '../site_constants/'; // alternative location used as a default

require_once( "{$require_prefix}wp-config-constants.php" );

By storing these files in a dedicated and carefully controlled location, we can avoid opening up access to anything that we don’t want to open access to, and of course we take them out of the web-accessible area altogether. In addition, we avoid potential problems caused by WordPress’s built-in (and sensible) limitation to look only one level higher than usual for its wp-config.php file. I.e., it doesn’t matter how many levels down your WordPress installation lives, its wp-config.php file remains where it expects it to be, but all the important contents of that file live elsewhere. Even badly behaved themes and plugins that talk directly to wp-config.php — even some (but probably not all) that write directly to it — can continue to function properly.

• security
• WordPress