Get Started
Guides April 24, 2026 8 min read

How to Secure wp-config.php: The Most Important File in WordPress

wp-config.php is the most sensitive file in any WordPress installation. It contains your database credentials, security keys, salts, and core configuration settings. If an attacker reads this file, they have everything they need to take over your site. This guide covers every security measure you should apply to wp-config.php, from file permissions and .htaccess protection to hardening constants that lock down your installation.

Wp-config php security hardening wordpress: What Is in wp-config.php

wp-config.php contains your database name, database username, database password, database host, table prefix, authentication keys and salts, and a variety of configuration constants. It is the central configuration file for WordPress and is required for the CMS to function. Without wp-config.php, WordPress cannot connect to the database and will show a setup screen.

The file is created during WordPress installation. By default, it sits in your WordPress root directory (public_html or www). Because it contains plaintext database credentials, it is the primary target for attackers who gain read access to your server file system. Protecting it is your highest priority file-level security task.

Wp-config php security hardening wordpress: Move wp-config.php Above the Web Root

WordPress actually looks for wp-config.php one directory above the WordPress installation before checking the root directory. This means you can move it outside your public_html or www folder. If wp-config.php is not in the web-accessible directory, it cannot be read through a web request, even if something goes wrong with your server configuration.

To do this, move wp-config.php to the directory above your WordPress root. For example, from /home/user/public_html/wp-config.php to /home/user/wp-config.php. WordPress finds it automatically. This is one of the simplest and most effective security measures you can take, yet many site owners do not know it is possible.

# Move wp-config.php above the web root
mv /home/user/public_html/wp-config.php /home/user/wp-config.php

# Verify it was moved
ls -la /home/user/wp-config.php

After moving the file, visit your WordPress site to confirm everything still works. If your site loads normally, the move was successful. If you see a setup screen, WordPress cannot find the file in its parent directory and you may need to check the path.

Set the Correct File Permissions

wp-config.php should be set to 600 or 640 on most servers. Permission 600 means only the file owner can read and write it. Permission 640 adds read access for the group. Never use 644 or higher, because that makes wp-config.php world-readable.

chmod 600 /path/to/wordpress/wp-config.php

Some hosting environments, especially those using PHP-FPM with different users for FTP and web server, need 640 with the correct group ownership. Test this on a staging site first. If you set permissions too restrictive and your web server cannot read the file, your site will show a blank white screen or a database connection error.

To check the current permissions:

ls -la /path/to/wordpress/wp-config.php
# Expected: -rw------- (600) or -rw-r----- (640)

Protect wp-config.php with .htaccess

Even with correct permissions, adding a .htaccess rule provides defense in depth. Add this to your root .htaccess or an .htaccess file in the same directory as wp-config.php:

<Files wp-config.php>
    Order Deny,Allow
    Deny from all
</Files>

This rule tells Apache to deny all external requests to wp-config.php. Even if someone guessed the exact path and the file permissions somehow allowed reading, this rule blocks the HTTP request before WordPress loads. Note that this rule only works if wp-config.php is in a web-accessible directory. If you moved it above the web root, this rule is optional but still adds an extra layer of protection.

Trusti Security’s Directory Protection and Hardening modules help automate file-level protection across your site. While wp-config.php protection is best done manually, the plugin handles the rest of your sensitive directories and files.

Disable File Editing

WordPress has a built-in theme and plugin file editor accessible from the admin dashboard under Appearance > Theme Editor and Plugins > Plugin Editor. If an attacker gains admin access, they can use this editor to insert malicious code directly into your theme files. Disable it by adding this constant to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

This constant removes the editor menus and blocks any attempt to edit files through the WordPress admin interface. It does not affect file editing via FTP, SSH, or your hosting control panel. This is a best practice recommended by WordPress itself and is one of the first hardening steps every site owner should implement.

WP_DEBUG: When to Enable and When to Disable

The WP_DEBUG constant controls error reporting in WordPress. When enabled, PHP errors, warnings, and notices are displayed on your site. This is useful for development and staging environments but dangerous on production sites because it can reveal sensitive information about your server configuration.

// Enable debug (development only)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// Disable debug (production)
define('WP_DEBUG', false);

On production sites, WP_DEBUG should be set to false. If you need to troubleshoot an issue, enable WP_DEBUG_LOG to write errors to a log file (wp-content/debug.log) without displaying them on the site. Remember to disable debug logging and delete the debug.log file after troubleshooting, as it can contain database query strings and other sensitive information.

Automatic Update Settings

WordPress has several constants that control automatic updates. Configuring these properly ensures you receive security updates without unexpected behavior:

// Enable automatic updates for all types (core, plugins, themes)
define('WP_AUTO_UPDATE_CORE', true);

// Disable all automatic updates
define('WP_AUTO_UPDATE_CORE', false);

// Only enable minor core updates (default behavior)
define('WP_AUTO_UPDATE_CORE', 'minor');

// Disable automatic plugin updates
add_filter('auto_update_plugin', '__return_false');

// Disable automatic theme updates
add_filter('auto_update_theme', '__return_false');

The recommended setting for most sites is to enable automatic updates for minor core releases and security releases, while manually managing major version upgrades. Use a staging site to test major version updates before applying them to production. Trusti Security can help manage update schedules and notify you when updates are available.

WP_MEMORY_LIMIT and Performance Settings

Setting the PHP memory limit in wp-config.php ensures WordPress has enough memory to operate, especially on sites with many plugins or large media files:

// Increase PHP memory limit for WordPress
define('WP_MEMORY_LIMIT', '256M');

// Increase memory limit for admin area (especially media-heavy pages)
define('WP_MAX_MEMORY_LIMIT', '512M');

WP_MEMORY_LIMIT sets the maximum amount of memory that PHP can consume for the frontend. WP_MAX_MEMORY_LIMIT applies specifically to the admin dashboard, where memory usage is typically higher due to media processing, plugin management, and data visualization. The default is 40MB for single sites and 64MB for multisite. Setting these to 256M and 512M respectively is a safe upgrade for most sites.

Use Strong Authentication Keys and Salts

If your wp-config.php still uses the default salts from a fresh WordPress installation, or salts you set years ago, generate new ones immediately. Authentication keys and salts are used to encrypt cookies and create secure tokens for user sessions. If an attacker obtains your salts, they can forge session cookies and impersonate any user.

Use the WordPress API to generate unique salts at https://api.wordpress.org/secret-key/1.1/salt/ and replace the existing AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding SALT values in wp-config.php.

# Generate new salts via WP-CLI
wp config shuffle-salts

# Or via shell
curl -s https://api.wordpress.org/secret-key/1.1/salt/

Rotating salts every 6 to 12 months invalidates all existing login cookies and forces re-authentication. This can help if an attacker has stolen session tokens that you don’t know about. Note that rotating salts logs everyone out, including yourself. Plan this during a maintenance window.

What to Store in wp-config.php and What to Avoid

wp-config.php is the right place for:

  • Database credentials (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)
  • Table prefix ($table_prefix)
  • Authentication keys and salts (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and salts)
  • WordPress debugging constants (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY)
  • Performance settings (WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_POST_REVISIONS)
  • Security constants (DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS)
  • Automatic update settings (WP_AUTO_UPDATE_CORE)

Do NOT store in wp-config.php: plaintext API keys for third-party services (use a dedicated plugin or environment variables), hardcoded admin passwords, or custom PHP functions that belong in a plugin or theme functions.php. wp-config.php is for configuration, not application logic.

Complete wp-config.php Security Template

Here is a secure wp-config.php template with all the recommended security constants. Add these after the database settings but before the “That’s all, stop editing!” comment:

// Security hardening constants
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', false); // Set to true to block plugin/theme installs

// Debug settings (keep false on production)
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);

// Memory settings
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// Performance settings
define('WP_POST_REVISIONS', 5); // Limit post revisions
define('EMPTY_TRASH_DAYS', 30);  // Empty trash after 30 days

// Automatic updates
define('WP_AUTO_UPDATE_CORE', 'minor');

// SSL and cookies
define('FORCE_SSL_ADMIN', true);
define('COOKIE_DOMAIN', false);
define('COOKIE_HASH', 'your_custom_hash_here');

The FORCE_SSL_ADMIN constant ensures the login and admin areas are always served over HTTPS, even if the frontend is not. This prevents session hijacking via unencrypted admin traffic. Set this to true if you have an SSL certificate installed, which every site should.

Trusti Security for wp-config.php Protection

While wp-config.php protection is primarily a manual setup, Trusti Security helps by monitoring for configuration changes. The File Integrity Monitor alerts you if wp-config.php or any other critical file is modified. The Admin Activity Log tracks when wp-config.php is accessed or edited through the WordPress admin. Combined with proper file permissions and .htaccess protection, Trusti Security provides the monitoring layer to detect unauthorized changes.

wp-config.php is the gatekeeper to your entire WordPress installation. Protect it with multiple layers: correct file permissions, .htaccess rules, moving it above the web root, and hardening constants that limit what attackers can do even if they gain access elsewhere. These measures together make your site fundamentally more secure.

Related Articles