Subtle diagonal pinstripe pattern in light grey and cream, giving an impression of printed editorial paper

Securing wp-config.php with Safe Permissions and Placement

The wp-config.php file contains the settings WordPress needs to connect to its database and generate authentication keys. It may include the database name, username, password, host, security salts and other values that should never be exposed through a browser or shared unnecessarily with other users on the server.

A secure setup uses several controls together: restrictive file permissions, correct ownership, a location outside the public web root where practical, protected backups and sensible server configuration. The safest values depend on whether the site runs on managed WordPress hosting, a VPS, a dedicated server, Docker or a shared Australian hosting account.

Why wp-config.php deserves special protection

A compromised configuration file can reveal database credentials even when WordPress itself has been updated. An attacker who obtains those credentials may connect directly to MySQL, read customer records, alter administrator accounts or insert malicious content into posts and options. The database password can also provide a route into other applications when hosting accounts reuse credentials.

The file contains authentication salts as well as connection details. Salts help protect logged-in sessions and password-related cookies. If an attacker changes them, existing sessions are invalidated, which is useful after a suspected breach. However, changing salts logs every user out and should be planned during an incident rather than treated as a routine permission change.

Avoid placing API keys, payment credentials or long-lived service tokens in wp-config.php unless the application genuinely requires them there. Values in the file are protected from ordinary web requests, but they remain visible to administrators, deployment systems, backups and any process with permission to read the file. A secret manager or environment variable may be a better option for larger installations.

Set restrictive permissions without breaking WordPress

File permissions control which users and processes can read or modify a file. On Linux servers, a common starting point for wp-config.php is 600, which allows the owner to read and write while denying access to the group and everyone else. Some hosting environments require the web server process to read the file through group membership, making 640 or 440 more appropriate.

The correct setting depends on ownership. If PHP-FPM runs as the file owner, 600 can work well. If files belong to a deployment user and PHP runs under a separate web-server group, the file may need group-read access, such as 640, with a carefully controlled group. A permission value that looks secure but prevents PHP from reading the file can cause database connection errors or a blank page.

Use commands such as these only after checking the account and group arrangement:

chown deploy:www-data wp-config.php
chmod 640 wp-config.php

On a server where the PHP process and owner are the same account, this may be more suitable:

chown www-data:www-data wp-config.php
chmod 600 wp-config.php

Do not use 777, 666 or broad write access as a quick fix. World-writable configuration files allow another compromised site, account or process on the same machine to replace database credentials or inject PHP code. Shared hosting providers in Australia may apply their own ownership rules, so confirm the expected permissions in the control panel or hosting documentation before changing them.

Move the file outside the public web root

WordPress can load wp-config.php from the directory above the installation directory. For example, if the site is installed at /var/www/example/public, the file can often be stored at /var/www/example/wp-config.php. WordPress checks the parent directory when the expected file is absent from the document root.

Keeping configuration outside the public directory reduces exposure if the web server is misconfigured or PHP stops being interpreted. It also separates application code from sensitive settings, which can make deployment and backup policies clearer. This is particularly useful on a VPS hosting several sites in Sydney or Melbourne, where each virtual host should have a separate configuration boundary.

Placement outside the document root is a defence in depth measure, not a substitute for permissions. A server rule, backup archive or accidental directory listing can still expose a file stored in the wrong place. Confirm the result by requesting ordinary URLs and checking that the site loads normally, then verify that a direct request to /wp-config.php does not return its source code.

Apache and Nginx should both be configured to deny access to sensitive files. A typical Apache rule is:

<Files "wp-config.php">
    Require all denied
</Files>

Nginx normally does not serve PHP source when PHP-FPM is configured correctly, but an explicit location rule can add protection:

location = /wp-config.php {
    deny all;
}

Test configuration changes with the relevant syntax command before reloading the service. A mistake in an Nginx server block can take an entire site offline.

Manage ownership, deployment and backups

Ownership should follow the principle of least privilege. The account that deploys themes and plugins does not always need permission to edit database credentials. On a production server, a deployment user can own application files while a controlled release process changes wp-config.php. This limits the damage caused by a compromised WordPress administrator or vulnerable plugin.

Do not assume that a secure live file remains secure in a backup. Hosting snapshots, Git repositories, staging copies, migration archives and local downloads often contain the same credentials. Never commit wp-config.php to a public repository. If it must be stored in version control for a private deployment process, use a template containing placeholders and inject secrets during deployment.

Backups should be encrypted in transit and at rest, with access limited to the people and systems that need restoration rights. Keep a tested backup away from the production server. For an Australian business processing customer information, consider the Privacy Act, the Notifiable Data Breaches scheme and contractual requirements when deciding where backups are stored and who can access them.

Staging sites need special attention. A copied wp-config.php may point to the production database, allowing testing code or a staging administrator to change live data. Use a separate database, separate credentials and separate salts. Remove old migration files, temporary archives and installer scripts after each deployment.

Use safer configuration patterns

Define database credentials with the smallest practical database privileges. The WordPress database user generally needs access to its own WordPress database, but it should not have administrative rights over every database on the server. Avoid using the MySQL root account in wp-config.php.

Keep the standard security constants present and unique:

define( 'AUTH_KEY',         'replace-with-a-long-random-value' );
define( 'SECURE_AUTH_KEY',  'replace-with-a-long-random-value' );
define( 'LOGGED_IN_KEY',    'replace-with-a-long-random-value' );
define( 'NONCE_KEY',        'replace-with-a-long-random-value' );
define( 'AUTH_SALT',        'replace-with-a-long-random-value' );
define( 'SECURE_AUTH_SALT', 'replace-with-a-long-random-value' );
define( 'LOGGED_IN_SALT',   'replace-with-a-long-random-value' );
define( 'NONCE_SALT',       'replace-with-a-long-random-value' );

Generate unique random values rather than copying keys between sites. A site selling goods through WooCommerce should have different salts from its development and staging environments. If salts or database credentials are exposed, rotate them after investigating how the exposure occurred.

Production sites should generally run with debugging disabled:

define( 'WP_DEBUG', false );

Logging can be enabled temporarily for diagnosis, but error logs may expose file paths, SQL statements or secret values. Store logs outside the public directory, restrict their permissions and remove old copies. If a change produces a white screen, review the PHP error log before editing configuration repeatedly; a PHP syntax error guide can help distinguish a parse failure from a permissions problem.

Verify the protection during maintenance

Security settings should be tested after changing hosting, PHP versions, deployment tools or ownership. Check the effective identity of the PHP-FPM worker, inspect the file with ls -l, and confirm that WordPress can read the file without granting unnecessary write access.

A useful verification process includes a normal front-end request, an administrator login, a database-backed action and a direct request for the configuration path. Review web-server logs for unexpected requests containing wp-config.php, backup extensions or common discovery paths. If the file has been downloaded, assume its secrets are compromised and rotate database passwords, salts and third-party keys.

Containerised WordPress installations need equivalent controls inside the container and on mounted volumes. A read-only configuration mount can prevent runtime modification, while environment variables can keep credentials outside the image. Do not bake live secrets into a Docker image, because image layers may remain available in registries and build caches.

On managed hosting, you may not be able to move the file or change ownership. In that case, use the provider’s supported permission model, enable multi-factor authentication, restrict control-panel access and ask whether server-level rules already block direct access. A well-managed host in Brisbane or Perth may provide stronger isolation than an incorrectly configured self-managed VPS.

Compare common deployment choices

The best arrangement balances confidentiality, compatibility and operational simplicity. Moving the file above the document root is valuable, but it should be implemented in a way that the hosting platform supports and that future administrators can understand.

Environment Recommended location Typical permission approach Main consideration
Single-owner VPS Parent directory of the public root 600 where PHP runs as owner Confirm PHP-FPM ownership
Separate deployment and web users Parent directory or protected root 640 with a restricted web group Avoid broad group membership
Shared hosting Provider-supported WordPress path Usually provider-defined Do not override platform ownership blindly
Docker or containers Outside the image, mounted securely Read-only mount or controlled runtime access Protect environment and registry secrets
Managed WordPress Platform-managed location Set by the host Use MFA and provider controls

Safeguards worth standardising

These controls suit a wide range of WordPress sites, from a local trades business in Adelaide to a national WooCommerce store serving customers across Australia. Regular permission reviews, tested backups and careful deployment practices keep wp-config.php protected as the surrounding hosting environment changes.