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

Open wp-config.php in your site root, next to wp-admin and wp-content. Search for WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY first. If those lines already exist, set them to the values below instead of adding duplicates. If none of them exist, paste them above the line that says stop editing:

php

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, find .htaccess next to wp-admin and wp-content and deny browser access:

apache

<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.

Only run the command below if you have SSH access to the server.

bash

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 the 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 fixed price with rollback-safe changes.

Questions answered

wp-config.php security FAQs

Answers about protecting WordPress credentials, safe permissions, debug settings, security keys, and signs that configuration was exposed.

Does DISALLOW_FILE_EDIT break page builders?

No. It only removes the built-in theme and plugin code editors from wp-admin. Builders and SFTP still work.

Can attackers still read wp-config with 644 permissions?

644 is world-readable on some shared hosts. Tighten to 440 or move the file above web root when possible.

Should I put database passwords in environment variables?

Advanced setups use env vars in wp-config.php. Most small business hosts use standard defines. Follow host docs.

Is wp-config.php backup safe in Dropbox?

No. Encrypted password managers or the BugShield Vault are appropriate for credential storage.

Why is wp-config.php sensitive?

It normally contains database credentials, security keys, table settings, and environment-specific configuration that could help an attacker access or impersonate the site.

Should I move wp-config.php above the WordPress web root?

WordPress can read it one level above the installation in supported layouts. Confirm your host and deployment process support this before moving the file.

How should I protect database credentials in wp-config.php?

Use a unique least-privilege database user, restrict file access, avoid sharing copies through email, and rotate the password if the file may have been exposed.

Should WP_DEBUG be enabled in production?

Leave visible debug output off. Enable private logging only for a controlled investigation, protect the log from public access, and disable it when troubleshooting ends.

Should I change WordPress security keys in wp-config.php?

Rotate keys after suspected compromise, staff access changes, or accidental file exposure. The change safely logs out existing sessions.

How do I know whether wp-config.php was compromised?

Review file-change history, web and SFTP logs, unexpected administrators, database access, altered salts, injected PHP, and any public or backup copy of the file.

Keep troubleshooting

Learn how to secure wp-config.php.