How to secure wp-config.php

What this problem looks like

wp-config.php is the crown jewels of a WordPress install. Hardening combines file location, chmod, server deny rules, and constants that reduce attack surface in admin.

Some hosts already place wp-config outside public_html. Check before duplicating effort. Never commit wp-config.php to Git or paste it into support tickets.

Step 1: Add recommended security constants

Paste above the stop editing line in wp-config.php on production sites:

define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Step 2: Move wp-config.php above web root (optional)

On VPS and some shared hosts, move wp-config.php one folder above public_html. WordPress searches parent directories automatically. Update paths inside the file if you reference absolute directories.

Step 3: Block HTTP access to wp-config.php

If the file must stay in web root, deny browser access in .htaccess:

<Files wp-config.php>
order allow,deny
deny from all
</Files>

Step 4: Set restrictive permissions

Try chmod 440 on wp-config.php. If the site fails to load, use 600 or 644 per host documentation. Ownership should be the web server user, not world-readable.

chmod 440 wp-config.php

Step 5: Rotate keys and limit credentials exposure

Use unique database passwords and rotate AUTH keys after any breach. Store SFTP and database credentials in a password manager or BugShield Vault, not in email or Slack.

When to stop DIY and hire help

Misconfigured wp-config hardening can whitescreen production or block legitimate updates. BugShield secures WordPress configuration at a confirmed price with rollback-safe changes.