wp-config.php permissions: why 600 or 640, never more

wp-config.php is the most sensitive file in a WordPress site. It contains your database password, database name and the eight secret keys that encrypt login cookies. If it leaks, whoever reads it can connect directly to the database, forge admin sessions and exfiltrate everything. File permissions are the first line of defence.

Why this matters

On shared hosting, hundreds of tenants share the same hardware. If wp-config.php has permissions 644 (-rw-r--r--), any other tenant on that server can read it through a Local File Inclusion bug in their plugin, or with a trivial PHP script that calls file_get_contents. Even on a dedicated server, a vulnerable plugin can read configuration files of other plugins when permissions are open. Permission 777 (-rwxrwxrwx) is catastrophic: anyone can also write to the file and change the database password. The correct permission is 600 (-rw-------) - only the file owner reads and writes, no one else sees anything. When PHP-FPM runs as a different user from the file owner, 640 (-rw-r-----) with the group set to www-data is the right answer.

How to detect

Over SSH run ls -la wp-config.php. The output starts with the permission string. -rw------- = 600 (good). -rw-r--r-- = 644 (vulnerable on shared hosting). -rwxrwxrwx = 777 (catastrophic). The RankPlus audit runs stat() on the file and reads the mode. Manually over FTP/SFTP: right-click wp-config.php > File Permissions / Properties - it should show 600 or 640.

How to fix

1. Back up the file before you change anything.
2. Over SSH:

   cd /path/to/wordpress
   chmod 600 wp-config.php
   ls -la wp-config.php

3. If the site returns a white screen or 500 after the change, PHP-FPM is running as a different user and cannot read the file. Try 640:

   chmod 640 wp-config.php
   chgrp www-data wp-config.php

4. The group name varies: www-data on Ubuntu/Debian, apache on CentOS, nobody on some shared hosts. Check with 'ps -ef | grep php-fpm' which user runs PHP.
5. Over FTP/SFTP (when SSH is unavailable): right-click > Properties > enter 600 in the Numeric value field. Do not tick 'Recurse into subdirectories'.
6. Apply similar hardening to other sensitive files: .htaccess (644), wp-config-sample.php (you can delete it entirely), debug.log (640).
7. Confirm HTTP access is blocked: open https://example.com/wp-config.php in a browser. You should get 403, never the file contents.

Common mistakes

Do not run FileZilla with 'Recurse into subdirectories' and chmod 600 on the site root - you will strip execute bits from directories and break the site. Do not set 444 or 400 - if you ever need to edit the file you will have to chmod temporarily. Do not assume your host 'takes care of it' - verify. Do not solve a permission problem by asking support to set 777; that makes the problem several orders of magnitude worse.

Verifying the fix

Run ls -la wp-config.php - the output should start with -rw------- or -rw-r-----. Re-run the audit. Try to load https://example.com/wp-config.php in a browser - 403 or blank. Browse 5-10 other pages on the site to confirm it still works.