In shortwp-config.php is the most important file in a WordPress site: it holds the database name, user, password and the keys that encrypt login sessions. Anyone who reads it can reach all your site’s data. Protect it with 440 or 400 permissions, block browser access, change the security keys after any breach, disable the file editor and delete any copy saved with another extension.
What does the file contain? #
DBDatabase credentialsDatabase name, user, password and host.
KSecurity keysAUTH_KEY and the other keys that encrypt login cookies.
⚙Site settingsTable prefix, debug mode, update and memory settings.
7 steps to protect it #
- Set permissions to 440 or 400: In the cPanel File Manager select the file, then “Change Permissions”. On our servers PHP runs as the account owner, so the site can still read it. Read secure file permissions.
- Block browser access: Add the rule below to your main
.htaccessfile. - Change the security keys after any breach: Generate new keys from the official WordPress generator
api.wordpress.org/secret-key/1.1/salt/and replace the old ones. This logs everyone out, including the attacker. - Disable the dashboard file editor: Add
define('DISALLOW_FILE_EDIT', true);so anyone who gets into your dashboard cannot edit theme and plugin files from it. - Turn debug mode off: Set
WP_DEBUGto false on a live site so file paths and errors are not shown to visitors. - Delete exposed copies: A file such as
wp-config.php.bakorwp-config.oldis not run as PHP, so it may be readable as plain text with your password. Remove any copy like this from the site folder. - Use a strong database password: If you suspect the file leaked, change it in cPanel and then update it in the file.
<Files wp-config.php> Require all denied </Files>
Before editing: save a copy of the file on your computer. A small mistake stops the whole site, and the copy restores it in seconds.
Can you move the file outside the site folder? WordPress also looks for it one folder up, but this does not suit every case, such as sites in subfolders. 440 permissions and blocked access are enough for most sites.
How Hyyat Host protects your site #
- CloudLinux isolates every account, so other sites on the server cannot read your files.
- ModSecurity and Imunify360 rules block known requests that try to read configuration files.
- ImunifyAV scans files daily and detects malicious code added to WordPress files.
Frequently asked questions #
Will 400 permissions break my site?
Not on Hyyat Host servers, because PHP runs as the account owner. If an error appears after the change, try 440 or 644.
When should I change the security keys?
After any breach or leaked admin password, or when a staff member with access leaves. It only logs everyone out and does not harm the site.
Can anyone read the file from a browser?
Usually not, because the server runs it as PHP and does not show its contents. The real risk is copies with other extensions or PHP failing, so add the block rule.
