Do I need a security plugin like Wordfence?

Not always. A security plugin adds a firewall, login protection and malware scanning inside WordPress. If your host already runs a firewall, limits login attempts and scans files, a plugin adds little. On basic shared hosting with none of that, one well-maintained security plugin is worth having. Never run two.

Is WordPress less secure than other platforms?

Core WordPress is well maintained and has a dedicated security team. The risk comes from the plugins and themes added to it and from sites nobody updates. A WordPress site with few plugins, weekly updates and two-factor logins is a hard target. A neglected one with thirty plugins is an easy one.

Should I disable XML-RPC?

If nothing on your site uses it, yes. It is an older remote-access interface that bots use for password guessing. Jetpack and some publishing apps rely on it, so check first. Blocking xmlrpc.php at the server or firewall is more complete than a plugin toggle, which may only disable the parts that need a login.

WordPress security: the ten things that stop most attacks

Most WordPress hacks come through outdated plugins and stolen logins, not core. Ten measures that stop most attacks, in order of impact, with the config.

By Sohail Hussain9 November 20265 min read

Most WordPress sites are not hacked through WordPress itself. They are hacked through an out-of-date or abandoned plugin, a reused password, or an admin account nobody remembered. Ten measures stop most of it: keep everything updated, remove what you do not use, turn on two-factor login, use unique passwords, give people only the access they need, limit login attempts, turn off the dashboard file editor, set sane file permissions and HTTPS, keep off-site backups, and watch for changes. The first five do most of the work and cost nothing.

This is the list we apply to every site we look after under website care and maintenance, in roughly this order of impact.

Where do WordPress attacks actually come from?

Plugins and themes, mostly. Core WordPress has a security team, automatic minor updates and thousands of people reading its code. A plugin with 2,000 installs written by one developer has none of that. Vulnerability databases record far more plugin flaws than core flaws every year.

The second route is credentials. Bots try common usernames and leaked passwords against wp-login.php around the clock. A password reused from a breached service will be tried eventually.

The third is the hosting account. On shared hosting with several sites in one account, one neglected site can infect the rest. FTP passwords saved on an infected office computer are another classic way in, which is why the official recovery guidance asks you to scan your own machines too.

Automated attacks do not pick targets. They scan every site they can find for a known flaw, so "we are too small to be a target" does not apply.

Which five measures stop most attacks?

1. Keep core, plugins and themes updated

Most exploited flaws already have a fix; the hacked sites had not applied it. Minor core releases install automatically by default. Plugins and themes need either auto-updates (switched on per plugin from the Plugins screen) or someone applying updates every week. How to update WordPress safely covers the routine. Keep PHP on a supported version too. As of October 2026, WordPress.org recommends PHP 8.3 or newer.

2. Remove what you do not use

Delete inactive plugins and unused themes, keeping one default theme as a fallback. Replace plugins that have not been updated in a year or have been closed on WordPress.org. Every plugin removed is one less thing to watch. How many WordPress plugins is too many has an audit method.

With two-factor authentication, a stolen password alone gets an attacker nothing. The Two Factor plugin from WordPress contributors, most security plugins and many managed hosts provide it. Require it for Administrators and Editors at least.

4. Use unique, long passwords, and no shared logins

One person, one account, one password from a password manager. A shared "office" login makes it impossible to remove one person's access without locking everyone out. Our password generator makes strong ones in the browser. Since WordPress 6.8, stored passwords are hashed with bcrypt, which makes a stolen database much harder to crack.

5. Give people only the access they need

Most staff need the Editor or Author role, not Administrator. Review the user list every quarter and remove people who have left. Many compromised sites have more administrators than anyone can explain.

What should be set at the server and in wp-config.php?

Rate-limit wp-login.php so bots cannot try thousands of passwords. A web application firewall at the host, or a service such as Cloudflare, blocks known attack patterns before they reach WordPress. If your host provides both, you may not need a security plugin at all.

7. Turn off the file editor in the dashboard

By default, an administrator can edit plugin and theme PHP files from inside WordPress. So can an attacker with an admin login. The WordPress hardening guide recommends switching it off in wp-config.php:

php

define( 'DISALLOW_FILE_EDIT', true );

If updates are deployed from version control rather than the dashboard, DISALLOW_FILE_MODS set to true also blocks installing and updating plugins and themes from the admin. Only use it if someone has another way to apply updates.

8. Set file permissions and use HTTPS everywhere

The hardening guide recommends 755 for directories, 644 for files, and 400 or 440 for wp-config.php, so only your user and the web server can read it. With SSH access:

bash

find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 /path/to/wordpress/wp-config.php

Our chmod calculator translates between these numbers and read, write and execute permissions. On Apache, the same guide blocks direct web access to wp-config.php with this at the top of .htaccess:

apache

<Files "wp-config.php">
Require all denied
</Files>

Serve every page over HTTPS with an automatic redirect from HTTP; most hosts issue free certificates. FORCE_SSL_ADMIN set to true in wp-config.php makes sure logins and the admin always use it.

How do you know if something gets through?

9. Keep off-site backups you have restored

Backups do not stop an attack; they make one survivable. Take them daily, store them away from the hosting account, and keep at least 30 days so you can go back to before an infection nobody noticed at first. How to back up a WordPress site properly has the setup.

10. Watch for changes

Uptime monitoring with alerts, so you hear about a defaced or broken site before customers do.
File integrity checks. With WP-CLI, wp core verify-checksums and wp plugin verify-checksums --all compare your files with the official copies on WordPress.org and list anything changed or added. Premium plugins not hosted on WordPress.org cannot be checked this way.
An activity log plugin, so you can see who changed what, and when.
Google Search Console, which emails you if Google detects hacked content or malware on the site.

Which security advice can you skip?

Some popular measures add little:

Changing the database table prefix on a live site. The hardening guide notes that a custom prefix blocks some automated SQL injection. Set one at install. Changing it later risks breaking the site for a small gain.
Hiding the WordPress version number. Bots do not check the version first; they simply try the exploit.
Stacking security plugins. Two security plugins conflict and slow the site. Pick one, or none if the host covers firewall and login protection.
Renaming the login URL. It cuts log noise, which is pleasant, but it is not protection. Two-factor login is.

If the site has already been compromised, these measures come after the cleanup. Start with WordPress keeps getting hacked: what to do. For where security fits into running WordPress as a whole, see WordPress for business websites.

Was this guide useful?