WordPress hardening: updates, fewer plugins and a locked wp-config.php

When a WordPress site is broken into, the cause is rarely a clever attack on WordPress core. Far more often it is an outdated plugin, an abandoned theme or an admin account with a reused password. This guide closes those gaps in order of impact, with the exact wp-config.php settings and server rules to copy. Plan an hour for a typical site, and take a full backup before you start.

Updates first: core, plugins, themes and PHP

WordPress installs minor core releases, which carry security fixes, automatically by default. Only the latest version is officially supported, so major releases should follow within weeks, not years. Since WordPress 5.5 you can also switch on automatic updates for each plugin and theme on the Plugins and Appearance screens. They run twice a day through WP-Cron, the built-in task scheduler, and by default WordPress emails the site owner about successful and failed updates.

To enable automatic updates for every plugin and theme at once, a small must-use plugin does the job. Files in wp-content/mu-plugins/ load automatically and cannot be switched off from the dashboard.

<?php
// Install updates for all plugins and themes automatically
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

PHP needs the same attention. WordPress recommends PHP 8.3 or newer, and older branches lose support on a fixed schedule: PHP 8.2 receives security fixes only until 31 December 2026. Most hosting panels let you switch the version per site. Test on a staging copy first, because old plugins are the usual reason an upgrade breaks.

Fewer plugins, fewer doors

Every plugin is code from another author, running with full access to your site and database. Deactivating a plugin is not enough: its files stay on the server, and some of them can still be requested directly. Delete what you do not use, including old themes. Keep the active theme, its parent theme if it has one, and at most one default theme for troubleshooting.

For the plugins you keep, ask these questions once a quarter:

• Does it still have an active maintainer and a recent update?
• Does it support your WordPress and PHP versions?
• Could core, or a plugin you already run, do the same job?
• Did it come from the official directory or the vendor itself? Download sites that give away paid plugins for free (so called nulled plugins) are a common source of backdoors.

Admin accounts: MFA, login limits and roles

WordPress core has neither multi-factor authentication (MFA) nor a limit on failed logins, so both come from a plugin or from your host. Choose an MFA plugin that supports authenticator apps or security keys, enforce it for every account that can publish or change settings, and store the recovery codes somewhere safe. A login limiter, or a rule at your host or firewall, slows down password guessing against wp-login.php.

Then apply least privilege: each person gets the lowest role that does the job. Editors manage all content, Authors publish their own posts and Contributors write drafts for review. Keep administrators to one or two named people, avoid an account called admin, and remove accounts when people leave. Review the application passwords section in each user profile as well, because these grant API access without the normal login screen.

Lock down wp-config.php and file permissions

wp-config.php holds your database password and the security keys, and it is also where you switch off risky features. Add these lines above the comment that says That's all, stop editing:

// Remove the theme and plugin file editor from the dashboard
define( 'DISALLOW_FILE_EDIT', true );

// Send logins and the admin area over HTTPS only
define( 'FORCE_SSL_ADMIN', true );

// Never show PHP errors to visitors on the live site
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Mark this installation as production
define( 'WP_ENVIRONMENT_TYPE', 'production' );

// Core updates: 'minor' is the default; true also installs major releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT removes the file editor, so a stolen admin session cannot turn into a code change with two clicks. It does not stop someone uploading a malicious plugin, which is why MFA matters more. If you suspect a compromise, replace the authentication keys and salts in the same file: that logs every user out.

File permissions decide who may change what. The official hardening guide recommends 755 for directories and 644 for files, with wp-config.php readable only by you and the web server. Run this in the WordPress root as the user who owns the files:

# Directories 755, files 644
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
# wp-config.php for owner and group only (use 400 if PHP runs as the file owner)
chmod 440 wp-config.php

Load the site straight afterwards. If it shows a database connection error, PHP can no longer read wp-config.php; ask your host which user and group PHP runs as, and adjust.

XML-RPC, the login page and a firewall

xmlrpc.php is an older remote publishing interface. Some apps and connected services still use it, but if yours do not, it is a door you can close. Attackers like it because it can accept many password attempts in a single request. The xmlrpc_enabled filter only switches off the methods that need a login, and pingbacks keep working, so blocking the file at the web server is cleaner:

<Files "xmlrpc.php">
    Require all denied
</Files>

location = /xmlrpc.php {
    deny all;
}

For Nginx, run nginx -t before you reload. For Apache, apachectl configtest checks the main configuration but not .htaccess, so open the site right after the change: a typo there shows up as error 500. Then request /xmlrpc.php and confirm you get a 403.

A web application firewall (WAF) filters requests before they reach WordPress. It can run at a CDN, on the server or as a plugin, and it can block attacks on a known plugin flaw until the fix is installed. Treat it as a seat belt, not as a reason to delay updates. Security headers belong in the same layer, and our explainer on security headers covers them.

Backups you have restored at least once

A complete backup covers the database, the whole wp-content directory and wp-config.php. Keep several versions, store at least one copy away from the web server with separate credentials, and encrypt it, because the database contains personal data. Daily backups suit most small sites, while busy shops may need more.

The test that matters is the restore. Once a quarter, restore the latest backup to a staging site and log in. A backup you have never restored is a hope, not a plan.

General information, checked on 31 October 2026. Test changes on one system first and keep a way back. Found something outdated? Tell the editors.