What is wp-config.php?

Table of Contents 5 sections

What is wp-config.php?

The wp-config.php file is the single most important configuration file in any WordPress installation. Located in the root directory of a WordPress site, this PHP file contains the essential settings that WordPress needs to connect to its database and operate correctly. It stores the database name, username, password, and host, as well as the database table prefix. Beyond database connectivity, wp-config.php holds authentication keys and salts, debugging flags, and various constants that control WordPress behaviour at a fundamental level.

When WordPress loads, wp-config.php is one of the very first files executed, making it foundational to the entire application lifecycle. Because it is a PHP file and not a static configuration format, it can contain dynamic logic, conditional settings, and environment-specific configurations. This flexibility is powerful but also means that a compromised wp-config.php file gives an attacker complete control over the WordPress installation, including direct database access and the ability to execute arbitrary PHP code.

Critical Settings in wp-config.php

The database connection constants (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) are the most sensitive values in wp-config.php. If an attacker obtains these credentials, they can connect directly to the database and read, modify, or delete any data including user accounts, posts, and plugin settings. The table prefix ($table_prefix) is also defined here; changing it from the default wp_ to a custom value adds a layer of obscurity that can prevent automated SQL injection attacks targeting default table names.

Authentication keys and salts are another critical component. WordPress uses eight security constants (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding salt counterparts) to strengthen the encryption of information stored in user cookies. These values should be long, random, and unique to each installation. If an attacker obtains these keys, they could potentially forge authentication cookies and impersonate any user, including administrators. WordPress provides an API endpoint at api.wordpress.org/secret-key that generates cryptographically random keys.

Security Hardening Through wp-config.php

wp-config.php provides several constants that directly enhance WordPress security when properly configured. Setting DISALLOW_FILE_EDIT to true disables the built-in theme and plugin editor in the WordPress admin dashboard, preventing attackers who gain admin access from directly modifying PHP files through the browser. Setting DISALLOW_FILE_MODS to true goes further by also preventing plugin and theme installations and updates through the dashboard, which is recommended for production environments where deployments should be handled through version control.

The FORCE_SSL_ADMIN constant ensures that all admin panel access is forced over HTTPS, protecting login credentials and session cookies from interception on unencrypted connections. Defining WP_DEBUG as false in production prevents sensitive error information from being displayed to visitors, which could reveal file paths, database queries, or other internal details useful to an attacker. The AUTOMATIC_UPDATER_DISABLED and WP_AUTO_UPDATE_CORE constants control automatic updates, which should be carefully configured to balance security patches with stability requirements.

Protecting the wp-config.php File

Given the extreme sensitivity of wp-config.php, protecting it from unauthorised access is paramount. One widely recommended technique is to move wp-config.php one directory level above the WordPress root. WordPress automatically checks the parent directory for the configuration file, and placing it outside the web-accessible root prevents it from being served directly by the web server in case of a PHP processing failure. This simple step significantly reduces the risk of accidental exposure.

Server-level protections should also be implemented. Apache users should add a directive to their .htaccess file that denies all HTTP access to wp-config.php. Nginx users should add a location block that returns a 403 or 404 for requests to the file. File permissions should be set to 400 or 440, allowing only the owner (and optionally the group) to read the file while preventing any write access. Regular security audits should verify that wp-config.php has not been modified unexpectedly, and file integrity monitoring tools can alert administrators to any unauthorised changes.

Common Misconfigurations and Risks

One of the most dangerous misconfigurations is leaving wp-config.php with overly permissive file permissions such as 644 or 666, which allows other users on a shared hosting environment to read its contents, including database credentials. Another common mistake is using the default authentication keys and salts or leaving them as the placeholder values from the sample configuration file, which dramatically weakens cookie security and makes session hijacking trivial.

Developers sometimes commit wp-config.php to version control repositories, inadvertently exposing database credentials and security keys in Git history. Even if the file is later removed, its contents remain in the repository history unless explicitly purged. Using environment variables or a separate configuration file that is excluded from version control is a best practice for managing sensitive values. Additionally, leaving debug mode enabled in production (WP_DEBUG = true) can expose stack traces, SQL queries, and file paths that provide attackers with valuable reconnaissance information.