Hardening · 2026-07-14

WordPress Hardening: 15 wp-config.php & Server Tweaks That Matter

wp-config.php is the most security-sensitive file in a WordPress install — and a few lines there, plus a handful of server tweaks, close some of the most-abused attack paths. Here are 15 practical WordPress hardening changes that actually matter, with the exact settings.

Check the externally-visible side first: run a free MageArgus scan for exposed files, headers and version leaks.

By the numbers

Disabling the file editor removes a one-click path from stolen login to webshell — OWASP / WordPress Codex
Blocking PHP in uploads neutralises the most common backdoor location — MageArgus

Secrets & keys

Set unique Authentication Unique Keys and Salts (generate fresh ones; rotating them logs everyone out).
Use a strong, unique database password.
Change the default wp_ table prefix on new installs.

Lock down the admin surface

define('DISALLOW_FILE_EDIT', true);   // no theme/plugin editor in admin
define('DISALLOW_FILE_MODS', true);   // optional: block installs/updates via admin
define('WP_AUTO_UPDATE_CORE', 'minor');

Disabling the in-admin file editor means a stolen login can't instantly drop a webshell through Appearance → Editor.

Protect wp-config and sensitive files

Deny web access to wp-config.php, .htaccess and similar, and set tight permissions:

chmod 600 wp-config.php
# nginx: location = /wp-config.php { deny all; }

Block PHP execution in uploads

Attackers love wp-content/uploads because your app writes there. Stop PHP running in it:

# Apache (.htaccess in uploads):
<FilesMatch "\.php$">Require all denied</FilesMatch>
# nginx:
location ~* /wp-content/uploads/.*\.php$ { deny all; }

Server & transport tweaks

HTTPS with HSTS; force it with FORCE_SSL_ADMIN.
Disable directory listing.
Disable XML-RPC if you don't use it (a common brute-force/DDoS vector).
Add security headers (CSP, X-Frame-Options, X-Content-Type-Options) — see headers guide.
Correct permissions: files 644, directories 755.

Frequently asked questions

Will DISALLOW_FILE_EDIT break my workflow?

Only if you edit theme or plugin code from the WordPress admin, which you shouldn't on production anyway. Make code changes via version control or SFTP. The setting removes a favourite attacker shortcut with no downside for most sites.

Is changing the table prefix worth it on an existing site?

It's a minor defence-in-depth measure and risky to change on a live database. Prioritise it only for new installs; on existing sites, focus on updates, login hardening and blocking PHP in uploads instead.