If you’ve just been asked to harden the live WordPress site in front of you, and you’re wondering how to secure site with wp config without taking it offline, you’re in the right place.
The safest approach is to make only the changes you can explain, test, and reverse.
This guide shows where wp-config.php helps, where the host or web server must take over, and how to check the site after each change. You’ll leave with a small, supportable hardening path instead of a long list of unexplained constants.
TL;DR: Back up the site, edit wp-config.php carefully, and use a small set of WordPress constants with a clear rollback path. Then ask your host or developer to handle direct file protection, permissions, redirects, and any change that depends on the server stack.
What wp-config.php does for WordPress security
wp-config.php can control some WordPress behavior, but it can’t secure a site by itself. It is the central configuration file for a WordPress installation, containing database connection settings and other values WordPress needs to start. The file is created during setup and is not part of the stock WordPress download, which is why accidental disclosure is serious.
If this is the live site in front of you, treat the file as one layer in your WordPress security. A secure site still needs strong administrator accounts, updates, HTTPS, host and web-server protection, backups, monitoring, and a recovery plan.
That distinction prevents two common mistakes. One is pasting a long list of constants without knowing what each one changes. The other is putting a server rule, PHP setting, or database change into wp-config.php because it appeared in the same security checklist. The safest configuration is the smallest one that matches the site’s deployment process, because it’s easier to test and reverse.
Make a restorable backup before editing
Create and verify a full backup before changing wp-config.php. The backup should include the WordPress files and database, and you’ll need to know how to restore it or have a host who can do that. A copy that exists but has never been checked is not a reliable rollback plan.
Edit a copy through the host’s file manager, SFTP, or another controlled deployment process. Avoid editing directly in a browser when the host provides a safer option. Before applying any setting below, read how to edit the wp-config.php file safely if you need a concrete file-editing workflow, and make sure you can identify the correct file, backup, and rollback method, because I treat that restore check as part of the backup, not as an optional extra.
📝 Note: If your host offers both a file manager and SFTP, use the method you can document and reverse, because the safest choice is the one another person can follow if the live site fails.
Before opening the file, keep this short checklist nearby:
- Use a full-site backup that includes both files and the database, and confirm how it will be restored.
- Work through SFTP or another secure, controlled connection when transferring the file.
- Check the syntax of each line before saving it.
- Make one change at a time and record what you changed.
- Validate the site after each change before moving on.
Keep the original file available until the site has passed its checks. This is the mistake I see most often, so make one related change at a time, preserve the existing quotation marks and semicolons, and place new constants before the line that loads WordPress, usually the require_once line near the end of the file. Do not add a second definition of a constant that already exists.
If a syntax error takes the site offline, restore the last known-good file instead of trying several fixes on the live site. If you can’t identify the correct file, backup, or rollback method, stop and ask the host or developer to make the change.
Start with the built-in editor control
Once that rollback path is clear, DISALLOW_FILE_EDIT removes the built-in code editor for plugins and themes from the WordPress dashboard. Add this constant to wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );It reduces the damage an attacker could do through a compromised administrator account, because that account can no longer use the dashboard editor to write PHP into a plugin or theme.
It does not protect the account itself, block all file changes, or replace two-factor authentication, server controls, backups, or malware monitoring. An attacker with server or SFTP access is outside the scope of this constant. It is a useful first control precisely because its purpose is narrow and easy to understand.
Do not automatically use DISALLOW_FILE_MODS as a stronger version. It can also block dashboard plugin and theme installation and updates. That may be correct for a site whose code is deployed through version control or a managed release process, but it is a poor default for an owner who relies on the WordPress dashboard for updates. Choose it only when the alternative deployment and update path is documented and tested.
📝 Note: If you rely on dashboard updates, check the alternative deployment path before enabling the broader setting, because a control that blocks changes can turn routine maintenance into an avoidable outage.
Require HTTPS for the administrator area after HTTPS works
With the editor decision made, FORCE_SSL_ADMIN tells WordPress to use HTTPS for administration after the site already has working HTTPS. Add this constant only after the SSL certificate and HTTPS setup have been checked.
define( 'FORCE_SSL_ADMIN', true );This is an administrator-transport setting. It does not redirect every public HTTP request to HTTPS. Public redirects belong in the web server, reverse proxy, or hosting configuration, where the whole request can be handled correctly.
Test the certificate, the public site, the login page, and the admin area before enabling the constant. A certificate problem, incorrect proxy configuration, or missing HTTPS information between the proxy and WordPress can cause a redirect loop or lock administrators out. If the site is behind a managed host or CDN, ask that provider how HTTPS is terminated and passed to WordPress before changing the file.
📝 Note: A working HTTPS padlock in the browser is only part of the check when a proxy or CDN sits in front of WordPress, so ask who terminates HTTPS and how that state reaches the application.
Do not use this setting as a substitute for a site-wide HTTPS migration. Confirm that the site, assets, forms, and third-party services work over HTTPS, then use the correct server or hosting control to redirect public HTTP requests to HTTPS.
Keep production debugging private
After HTTPS is working, keep WordPress error output hidden from visitors on a production site. Debugging can help a developer find a broken plugin or theme, but error output can expose file paths, configuration details, and other information to visitors.
If debugging isn’t needed, turn it off:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );These values do not replace a safe staging and logging process. When troubleshooting is necessary, use a staging copy or protected WordPress error logs reviewed by someone who can remove sensitive details. Turn debugging back off and clear any exposed output before returning the change to production. Do not paste a generic debug configuration into a live site without understanding where logs are written and who can read them.
Rotate salts when there is a reason to end sessions
Once debug output is private, regenerate the complete set of WordPress authentication keys and salts after a suspected compromise or important administrator turnover. These values help protect cookies and other security tokens. Replacing them invalidates existing login sessions, so every user must sign in again. That disruption is expected and is useful when the goal is to end access held by old or stolen sessions.
Do not rotate salts as a routine substitute for investigating a breach. During an incident, preserve the evidence and carry out a WordPress security audit covering administrator accounts, access logs, plugins, themes, hosting access, and other access paths. Salt rotation can close existing WordPress sessions, but it does not remove malware or fix a compromised server.
Never publish real salt values, passwords, API tokens, or database connection details in an article, ticket, screenshot, or code sample. Generate a fresh set through a trusted WordPress process and replace the existing key-and-salt block without changing unrelated configuration.
Put file protection at the correct layer
After deciding which WordPress settings belong in the file, direct file protection, permissions, and public redirects belong to the host or web-server layer, not to a WordPress constant. The web server must not return the contents of wp-config.php as text. It must also prevent accidental backup copies such as wp-config.php.bak from becoming downloadable. Ask the host to confirm how PHP files and backup files are handled, and how a direct request for the configuration file is denied without exposing its contents.
WordPress file permissions are also host-specific. There is no universal permission number that is safe on every server. The correct setting depends on the file owner, group, PHP and web-server execution model, host policy, and deployment tools. Have the host verify the permission and ownership rather than applying a random command from a checklist.
The FS_CHMOD_DIR and FS_CHMOD_FILE constants affect the permissions of items WordPress creates. They are not a direct replacement for setting the permissions of wp-config.php itself.
Moving the file above the web root or into a host-specific private directory can work in some environments, but it is a maintenance change, not a beginner default. The path must work for normal page requests, the dashboard, WP-CLI, cron, backups, and deployments. Test the complete workflow before making the old location unavailable, and keep a recovery path if the host’s WordPress setup does not support the move.
Treat database-prefix changes as a migration
When the host controls are understood, changing the database table prefix is a migration, not a complete security defense. On an existing site, every relevant table and reference must be renamed consistently, with a verified database backup and a tested recovery plan. A partial rename can break the site or leave configuration pointing at missing tables.
For a new installation, choosing a non-default prefix may reduce noise from basic automated guesses, but it is security through obscurity rather than a primary control. It does not protect stolen database access details, vulnerable code, weak accounts, or a server compromise. Do not perform this change on a live site just because a checklist says it is more secure.
Use an update process with staging and rollback
With migration work left alone unless it is supported, the right update policy is the one that applies patches promptly, checks the result, and restores the previous state when needed. Updates close known security gaps, but an update can also expose a compatibility problem with a plugin, theme, PHP version, or custom code.
Before applying WordPress security updates:
- Test the update in staging where practical.
- Make a full backup that you can restore.
- Read the release notes and watch for compatibility issues.
- Monitor the site after the update and confirm the rollback path.
For a site that updates through the dashboard, do not use DISALLOW_FILE_MODS without providing another tested path. For a site managed through deployment tooling, document who applies updates, where they are tested, how backups are made, and how rollback works. A staged update with a usable backup is safer than an untested collection of constants.
Verify the site after each change
Once the update path is clear, after editing wp-config.php, verify the front end, an important form, the login flow, the dashboard, and any scheduled or external integration that matters to the site. Confirm that the site is not displaying PHP or WordPress errors to visitors. If HTTPS was changed, check both the public site and the admin area from a fresh browser session.
Have the host verify that a direct request for wp-config.php and likely backup names cannot expose source code. Do not use a real secret to test this. Check that the file remains readable by the intended WordPress process, that updates still follow the expected path, and that the backup can actually restore the site.
FAQs
Can wp-config.php alone secure a WordPress site?
No, wp-config.php alone can’t secure a WordPress site. It can reduce specific risks, such as dashboard code editing and insecure administration transport, but it cannot replace strong accounts, updates, HTTPS, server controls, backups, monitoring, or incident response.
Which setting disables the WordPress theme and plugin editor?
Add DISALLOW_FILE_EDIT with a true value to wp-config.php. It removes the built-in dashboard editor. It does not prevent file changes through SFTP, the host, a deployment system, or a compromised server.
Does FORCE_SSL_ADMIN redirect the whole site to HTTPS?
No, FORCE_SSL_ADMIN does not redirect the whole site to HTTPS. It tells WordPress to use HTTPS for the administration area after HTTPS is working. A site-wide HTTP-to-HTTPS redirect belongs to the web server, reverse proxy, CDN, or host configuration.
Should I move or rename wp-config.php?
Only when the host and deployment process support it. A move can affect page requests, the dashboard, WP-CLI, cron, backups, and deployments. Moving or renaming the file is not a substitute for server access controls.
What permissions should wp-config.php have?
There is no safe number that applies to every host. The correct permissions depend on ownership, the PHP execution model, host policy, and deployment tools. Ask the host to set and verify the least access that keeps WordPress working.
Conclusion
The safest way to secure the live site in front of you with wp-config.php is to make a restorable backup, disable the dashboard editor, enable administrator HTTPS only after HTTPS is confirmed, keep production debug output private, and rotate salts when you need to end existing sessions. Keep server rules, permissions, direct file protection, redirects, and database migrations in the layer that controls them.
Before changing a live configuration file, confirm the rollback path, make one change at a time, and ask the host or developer to handle anything that depends on the server stack. Start with the backup and safe editing workflow, then verify the site before moving to the next control.
