Securing wp-config.php

wp-config.php holds your database credentials and your authentication salts. Anyone who reads it can read your entire database from anywhere your host allows connections.

Permissions

Set it to 400 (owner read only) or 440 if your server needs group read. WordPress does not need to write to it after installation. If your host insists on 644, that is a shared-hosting compromise, not a recommendation.

Constants worth setting

define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'DISALLOW_FILE_MODS', false ); // true blocks all plugin/theme installs and updates
define( 'FORCE_SSL_ADMIN', true );

• DISALLOW_FILE_EDIT — removes the dashboard code editor, a favourite persistence route after a session is hijacked.
• WP_DEBUG / WP_DEBUG_DISPLAY — debug output on a production site leaks paths, queries and sometimes credentials.
• FORCE_SSL_ADMIN — never send an admin session over plain HTTP.
• DISALLOW_FILE_MODS — strong but heavy-handed; it also blocks your own updates. Only use it where deployment is handled elsewhere.

Salts

The eight authentication keys and salts sign your login cookies. Replacing them invalidates every existing session — which is exactly what you want after a compromise, a departing administrator, or any doubt about a stolen cookie. Generate fresh values from the official WordPress secret-key service and paste them in.

Moving the file

WordPress will read wp-config.php from one directory above the install. It is a mild obscurity win and it is safe, but it is well below permissions and salts in usefulness. Do the first two before bothering with this.

Hardening reduces the damage. Patching removes the hole. Scan your site free to see what still needs patching.