# Short answer: yes #

The answer to this question is **yes** and to say otherwise is **probably irresponsible**.


----------


# Long answer: a real-world example #

Allow me to provide a very real example, from my very real server, where moving `wp-config.php` outside the web root **specifically prevented its contents from being captured**.

## The bug: ##

Take a look at this description of a bug in Plesk (fixed in 11.0.9 MU#27):

> [Plesk resets subdomain forwarding after syncing subscription with hosting plan (117199)][1]

Sounds harmless, right?

Well, here's what I did to trigger this bug:

 1. Set up a subdomain to redirect to another URL (e.g. `site.staging.server.com` to `site-staging.ssl.server.com`).
 1. Changed the subscription's service plan (e.g. its PHP configuration).

When I did this, Plesk reset the subdomain to defaults: serving the contents of `~/httpdocs/`, with no interpreters (e.g. PHP) active.

And I didn't notice. For weeks.

## The result: ##

 * With `wp-config.php` in the web root, a request to `/wp-config.php` would have downloaded the WordPress configuration file.
 * With `wp-config.php` outside the web root, a request to `/wp-config.php` downloaded a completely harmless file. The real `wp-config.php` file could not be downloaded.

Thus, it's obvious that moving `wp-config.php` outside the web root can have **bona fide security benefits in the real world**.


----------


# How to move `wp-config.php` to any location on your server #

WordPress will automatically look one directory above your WordPress installation for your `wp-config.php` file, so if that's where you've moved it, you're done!

But what if you've moved it somewhere else? Easy. Create a new `wp-config.php` in the WordPress directory with the following code:

    <?php
    
    /** Absolute path to the WordPress directory. */
    if ( !defined('ABSPATH') )
    	define('ABSPATH', dirname(__FILE__) . '/');
    
    /** Location of your WordPress configuration. */
    require_once(ABSPATH . '../phpdocs/wp-config.php');

(Be sure to change the above path to the actual path of your relocated `wp-config.php` file.)

If you run into a problem with `open_basedir`, just add the new path to the `open_basedir` directive in your PHP configuration:

    open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

That's it!


----------


# Addressing arguments to the contrary #

Every argument against moving `wp-config.php` outside the web root seems to hinge on false assumptions.

## Argument 1: If PHP is disabled, they're already in ##

> The only way someone is going to see that contents of
> [`wp-config.php`] is if they circumvent your servers PHP interpreter…
> If that happens, you're already in trouble: they have direct access to
> your server.

**FALSE**: The scenario I describe above is the result of a misconfiguration, not an intrusion.

## Argument 2: Accidentally disabling PHP is rare, and therefore insignificant ##

> If an attacker has enough access to change the PHP handler, you're
> already screwed. Accidental changes are very rare in my experience,
> and in that case it'd be easy to change the password.

**FALSE**: The scenario I describe above is the result of a bug in a common piece of server software, affecting a common server configuration. This is hardly "rare" (and besides, security means worrying about the rare scenario).

Changing the password after an intrusion hardly helps if sensitive information was picked up during the intrusion. Really, do we still think WordPress is only used for casual blogging, and that attackers are only interested in defacement? Let's worry about protecting our server, not just restoring it after somebody gets in.

## Argument 3: Denying access to `wp-config.php` is good enough ##

> You can restrict access to the file via your virtual host config or
> `.htaccess` – effectively limiting outside access to the file in the
> same way that moving outside the document root would.

**FALSE**: Imagine your server defaults for a virtual host are: no PHP, no `.htaccess`, `allow from all` (hardly unusual in a production environment). If your configuration is somehow reset during a routine operation – like, say, a panel update – everything will revert to its default state, and you're exposed.

**If your security model fails when settings are accidentally reset to defaults, you probably need more security.**

Why would anybody specifically recommend fewer layers of security? Expensive cars don't just have locks; they also have alarms, immobilizers, and GPS trackers. If something's worth protecting, do it right.

## Argument 4: Unauthorized access to `wp-config.php` is no big deal ##

> The database information is really the only sensitive stuff in
> [`wp-config.php`].

**FALSE**: The authentication keys and salts can be used in any number of potential hijacking attacks.

Even if database credentials were the only thing in `wp-config.php`, you should be *terrified* of an attacker getting their hands on them.

## Argument 5: Moving `wp-config.php` outside the web root actually makes a server *less* secure ##

> You still have to let WordPress access [`wp-config.php`], so you need
> to expand `open_basedir` to include the directory above the document
> root.

**FALSE**: Assuming `wp-config.php` is in `httpdocs/`, just move it to `../phpdocs/`, and set `open_basedir` to include only `httpdocs/` and `phpdocs/`. For instance:

    open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Remember to always include `/tmp/`, or your user `tmp/` directory, if you have one.)


----------


# Conclusion: configuration files should always always *always* be located outside the web root #

If you care about security, you should move `wp-config.php` outside your web root.


  [1]: http://kb.parallels.com/en/115179