WordPress security: the ten settings that stop most attacks

WordPress is not insecure. It is popular, which means the automated attacks that hit every site on the internet are written for it first. Nearly every WordPress site we have cleaned was missing several of the following, and none of them are hard. In order of how much each one matters.

1. Keep everything updated

Core, plugins, themes. Most break-ins use a hole that was published and patched weeks or months before, on a site that never installed the patch. Turn on automatic updates for minor core releases and for plugins from authors you trust. For the rest, a monthly routine with a staging test. Delete anything you do not use: a deactivated plugin is still a file an attacker can reach.

2. Real passwords and two-factor login

Every administrator gets a long unique password from a password manager, and two-factor authentication. This single change stops the credential-stuffing attacks that try leaked passwords from other sites, which is how a surprising share of “hacks” actually happen. No account called admin.

3. Limit login attempts

By default WordPress allows unlimited guesses. A small plugin or your host’s firewall should lock out an address after a few failures. This turns a brute-force attack from a matter of time into a matter of nothing.

4. Turn off XML-RPC

An old remote-access interface most sites never use, and a favourite for password guessing because it allows hundreds of attempts in one request. Block it at the server or with a plugin unless you specifically need it for the mobile app or a connected service.

5. Disable file editing in the dashboard

One line in wp-config.php stops the theme and plugin editors from working. If an attacker gets an admin login, this removes their easiest way to add code.

define( 'DISALLOW_FILE_EDIT', true );

6. Correct file permissions, and no PHP in uploads

Files at 644, folders at 755, wp-config.php tighter. And a rule at the server that refuses to run PHP from the uploads folder, because that is where uploaded backdoors go.

7. A firewall in front

A web application firewall blocks known attack patterns before they reach WordPress. At the edge, through Cloudflare or your host, is best, because the request never touches your server. A plugin firewall is second best and still worth having.

8. Backups you have tested

Daily, stored somewhere other than the site’s own server, kept for at least thirty days, and restored once to prove they work. A backup is not a security measure until you have seen it restore.

9. Fewer users, right roles

Everyone who does not need administrator gets editor or lower. Old accounts of people who left get removed the day they leave. Review the list quarterly, because an unknown admin account is one of the first signs of a compromise.

10. Security headers and HTTPS everywhere

HTTPS on every page, with the site forcing it. Then the response headers that tell browsers to protect visitors: content type options, frame options, referrer policy, a content security policy. They are a server setting, they take twenty minutes, and our scanner checks all of them.

What this list does not include

Renaming the login page, changing the database prefix, hiding the WordPress version. These are widely recommended and nearly useless: attackers do not care what your login page is called and their scripts do not check version numbers before trying an exploit. Do the ten above first. They stop the attacks that actually happen.

Run the scanner and you will see which of the outward-facing items are in place. The rest take an afternoon, and we do them as the first step of every care plan.