How to Protect wp-config.php in WordPress: Practical Steps

Why wp-config.php should be protected first

wp-config.php usually contains the database name, username, password and database server address. It also stores AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and the corresponding salts. WordPress uses these values to create and verify authentication cookies.

A leaked file does not always mean that the site has been completely compromised immediately, but the risk is high. An attacker may connect to the database, modify user accounts, insert malicious code or use the keys to forge sessions. This is why the file must not be published in a public repository, attached to support requests or sent through ordinary chats.

Elementor does not change the basic principles of protecting wp-config.php. The builder may add its own settings and cache, but WordPress credentials and access rules for the configuration file remain the same.

• Do not store wp-config.php in a public Git repository.
• Do not paste its full contents into chats, tickets or public discussions.
• If the file has already been exposed to third parties, change the database password and WordPress keys.

Disable PHP file editing from the admin area

WordPress may give administrators access to the built-in theme and plugin editor. If an administrator account is compromised, this editor can make it easier to install malicious PHP code. Disabling the editor does not replace account security, but it removes one unnecessary channel for making changes.

Add the constant to wp-config.php before the line indicating that editing is complete. It should be declared only once.

• After saving, check that the file contains no syntax errors.
• Use controlled deployment, SFTP or SSH with individual accounts for code changes.
• This constant does not block file uploads, plugin installation or the execution of malicious code that is already present.

define('DISALLOW_FILE_EDIT', true);

Where exactly to place the constant

In a typical configuration, add the line before a comment such as "That's all, stop editing" in wp-config.php. Do not place it inside an array, condition or comment. If the site runs in a container or uses automated deployment, make sure the change will not be overwritten during the next deployment.

Afterward, log in to the admin area with an account that has the necessary permissions and confirm that the built-in editor is no longer available. If you manage the site through a hosting control panel, also check whether it has a separate file-editing mechanism.

Enable HTTPS for the administration area

Passwords, cookies and session data should be transmitted over a secure connection. The FORCE_SSL_ADMIN constant forces HTTPS for WordPress logins and the administration area.

Add it only after the SSL certificate is working correctly on the domain. If HTTPS is only partially configured, an incorrect setup may cause redirect loops or make the admin area inaccessible.

• Check that the site opens through https:// without certificate warnings.
• Make sure the WordPress and site URLs are consistent with HTTPS.
• After making the change, test login, logout, media uploads and saving Elementor pages.
• If a CDN or reverse proxy operates in front of the site, make sure the server correctly identifies the original HTTPS request.

define('FORCE_SSL_ADMIN', true);

What to check after enabling it

Open the login page in a private browser window, sign in and visit several sections of the admin area. Check for mixed-content errors, where some resources are loaded over HTTP. Also test the Elementor editor separately: save changes, open the preview and load styles.

If the site operates behind a proxy, FORCE_SSL_ADMIN may not work as expected unless protocol headers are passed correctly. Coordinate such changes with the server administrator to avoid creating infinite redirects.

Replace WordPress keys and salts

The keys and salts in wp-config.php should be long, random and unique to the specific site. Do not use examples from the documentation, identical values across multiple projects or strings that are easy to guess.

Replacing these values invalidates active authentication cookies. After saving the changes, all users, including administrators, must sign in again. This is normal and expected behavior, not a sign of a WordPress malfunction.

• Create a new set of random values for each site.
• Do not send keys together with backups or configuration screenshots.
• After replacing them, test administrator login, password recovery and integrations that use authentication.
• If the keys may have been stolen, replace them together with the database password and passwords for privileged users.

When should you replace them again?

Regularly replacing keys without a specific reason is not always necessary: it terminates all active sessions and may interrupt the team's work. Instead, replace them after a suspected leak, access being shared with the wrong person, an account compromise or restoration of the site from an untrusted backup.

Notify editors and administrators before making the change so that they do not mistake a simultaneous logout for an error. After the operation, review login logs and make sure unknown sessions are no longer active.

Configure permissions and file location

Permissions for wp-config.php should allow reading only for the user or group that needs it to run the web server. Many configurations use 600 or 640, but the correct value depends on the file owner, the web server group and the deployment method.

Permission 600 means that the owner can read and modify the file while other users have no access. Permission 640 additionally allows the group to read it. Do not choose permissions arbitrarily: an excessively restrictive setting may break the site, while overly broad access may expose confidential data to other processes on the server.

• Check the file owner and group, not only the numeric permission value.
• Do not use 777 for wp-config.php or the site directory.
• After changing permissions, open the home page, the admin area and several pages with dynamic content.
• If your hosting provider does not allow you to change permissions yourself, consult its documentation or support team.

chmod 600 wp-config.php

Can wp-config.php be moved outside the public directory?

In a typical WordPress structure, the configuration file can be placed one level above the directory accessible to the web server. This reduces the risk of the file being downloaded directly because of an incorrect configuration. However, the result depends on the hosting structure and the way PHP is run.

Make a backup before moving the file and test the site in a staging environment. Do not move it to a directory that the PHP process cannot access, and do not leave a copy of wp-config.php in the public directory.

Protect the file at the web server level

WordPress rules cannot correct an incorrect Apache, Nginx or PHP configuration. If the server starts serving PHP files as plain text, wp-config.php could reveal all its secrets. In a normal configuration, PHP files are processed by the interpreter, but this should still be verified.

Check that a request to wp-config.php does not return its source code. The response should be a denial of access, an error or another result that does not disclose the file contents. Do not test this by publicly sharing the URL; a controlled check from a browser or command line is sufficient.

• Check access rules for configuration files and backups.
• Do not leave files with .bak, .old or .zip extensions, or configuration copies, in the public directory.
• Make sure PHP errors do not display secrets on pages shown to visitors.
• Restrict SSH, SFTP and the hosting panel to individual accounts and enable two-factor authentication where available.

Backups and final verification

Before editing wp-config.php, create a backup, but do not leave it in the public directory. Store the copy in a secure location with restricted access. Check not only that the backup was created, but also that it can be restored in a staging environment.

After making changes, go through a short checklist. This helps identify problems immediately rather than after a user complaint or a failure during an update.

• The site opens through HTTPS and the certificate is valid.
• Logging in to and out of the admin area works correctly.
• The built-in PHP file editor is disabled.
• After the keys are replaced, all required users can sign in again.
• Editing and saving Elementor pages work without errors.
• The owner and permissions for wp-config.php match the server configuration.
• The backup is stored outside the public directory and can be restored.
• The web server log contains no suspicious requests for configuration files.