Hardening WordPress Beyond Plugins: 12 Server and wp-config Settings

Security plugins help, but they have a clear limit: they run inside WordPress, meaning only after the request has already reached PHP. The strongest measures sit lower down — at the web server and in wp-config.php, where a plugin can't reach. These are settings you configure once; they stay active quietly and don't slow the site down.

Below are 12 concrete things you can check yourself or ask your host to apply. They don't replace common sense (good passwords, timely updates), but they raise the bar considerably for anyone trying to get in. And an honest warning: if someone promises you an "unhackable" site, walk away — security is layers, not a checkbox.

File permissions that don't leave doors open

Wrong permissions are one of the most common problems. The simple rule:

• directories: 755
• files: 644
• wp-config.php: 600 (or 640), readable only by the server user

Never 777 on anything — it means "anyone can write." Check ownership too: everything should be owned by the user PHP runs as, not root. A good sign is that WordPress itself shouldn't be able to edit theme files directly — if it can, so can an attacker who compromises an account. wp-config.php deserves separate treatment because it holds your database credentials.

wp-config.php — where the tone is set

This file is the heart of the install. A few lines that matter:

• Unique keys and salts, generated from the official WordPress service — they invalidate stolen sessions.
• define('DISALLOW_FILE_EDIT', true); — removes the theme/plugin editor from the admin so no one can inject code from a compromised account.
• define('FORCE_SSL_ADMIN', true); — forces HTTPS in the admin area.
• define('WP_DEBUG', false); and WP_DEBUG_DISPLAY off in production, so errors don't expose server paths.

Optionally, move wp-config.php one level above the public root and change the table prefix from wp_ to your own. Not silver bullets, but they reduce the surface.

Web server rules (Apache / Nginx)

This is where you block access before PHP even starts.

• Deny direct access to sensitive files: wp-config.php, .htaccess, readme.html, xmlrpc.php (if you don't use XML-RPC).
• Disable directory listing (Options -Indexes on Apache) so no one can browse your folders.
• Most important: stop PHP execution inside wp-content/uploads. If an attacker manages to upload a disguised .php file, with no execution there it's harmless.

On Nginx these are location blocks; on Apache, rules in .htaccess or the config. On shared hosting, ask support to apply them — it's a normal request.

Security headers — responses that tell the browser the rules

HTTP headers don't stop a server-side hack, but they close many browser-side attacks (clickjacking, content sniffing, downgrade to HTTP). Worth setting:

• Strict-Transport-Security (HSTS) — forces the browser to use HTTPS only.
• X-Content-Type-Options: nosniff — stops file-type guessing.
• X-Frame-Options: SAMEORIGIN (or CSP frame-ancestors) — anti-clickjacking.
• Referrer-Policy and Permissions-Policy — limit what leaks and which browser APIs are allowed.

Set them at the server level or through your platform's header rules. You can verify the result with any free public header scanner.

Database, accounts and maintenance

The last layer is hygiene:

• The database user should have only the rights it needs on its own database — not a global root account.
• No "admin" username, and long, unique passwords; ideally two-factor authentication on the admin accounts.
• Keep PHP and WordPress on a supported version — many breaches come from old software, not sophisticated attacks.
• An automated, tested backup, stored somewhere other than the server.

That's what a seriously handled install looks like at MPO Web Studio: we ship sites already hardened, remotely, nationwide, with these settings done from the start. If you'd like an opinion on your current site, message us on WhatsApp — we'll tell you honestly what's worth changing.