🔒 WordPress security in 2026: a complete guide to website protection

A WordPress site gets hacked not because the engine is "full of holes." It gets hacked because the owner postponed a plugin update, set the password admin123, and left xmlrpc.php open. Automated bots scan the internet continuously.

They don't care whether you sell handmade candles or run an online store. They will find and exploit the vulnerability. Login brute-force, SQL injection, shell upload through a vulnerable plugin, all of this runs around the clock.

The good news: you can build basic protection in an evening, without deep technical knowledge. Below is a proven set of measures, from installing a firewall to manual server hardening. We apply everything described here on our own projects.

💡 Quick overview:

• Install a firewall: BBQ or Wordfence, the first line of defense blocks most attacks before they even reach WordPress.
• Close typical entry points: xmlrpc.php, REST API for unauthenticated users, directory listing, the file editor in the admin panel.
• Configure automatic updates for core, themes, and plugins. An outdated plugin version is the main attack vector.
• Make a backup that is stored OFF the server. Without a backup, recovery after a hack means reinstalling WordPress from scratch.
• Enable two-factor authentication for all administrators. A password can be guessed; a second factor cannot.

Where they hit first: typical attack vectors

Most people picture a hacker as someone at a terminal, manually guessing the admin password. The reality is more mundane: virtually all attacks are carried out by bots following a script. They look for known vulnerabilities in plugins and themes, knock on xmlrpc.php, scan /wp-content/uploads/ for executable PHP files.

The main attack vectors against WordPress:

• Outdated plugins and themes. According to Sucuri reports, about 40% of hacked sites were using an outdated version of the CMS, a plugin, or a theme at the time of infection. Developers close holes with patches, but only if you apply those patches.

• Weak passwords. Brute-force attacks try tens of thousands of combinations per minute. A 6-character password without special characters is cracked instantly.

• Insecure hosting. Cheap shared hosting skimps on account isolation: if a neighboring site on the server is hacked, the attack can spill over to yours.

• Excessive write permissions. When the web server can write to any file, a shell uploaded through a hole gains full control over the site.

Understanding these vectors is half the defense. The other half is concrete action.

Level 1: quick protection you can set up in half an hour

This is where you should start today. Each action takes minutes, requires no code editing, and won't break your site.

Install a firewall: BBQ Firewall

BBQ Firewall is a plugin by Jeff Starr that works on a "set it and forget it" principle. No settings, no interference with .htaccess or the database. It simply blocks malicious URL requests before they reach WordPress: eval(), base64_decode, excessively long strings, injection attempts.

The plugin weighs under 10 KB and creates no load. At the same time, it catches SQL injection, XSS, executable file uploads, and attacks via "bad" referrers.

In practice, BBQ is often installed ON TOP of Wordfence or Solid Security; they solve different problems and don't conflict. A request-level firewall plus a full-featured security plugin gives you layered defense.

Enable two-factor authentication

A password can be guessed, intercepted, or bought in a dump of leaked databases. A second factor, a one-time code from an authenticator app, breaks all the math of brute-force attacks.

WordPress has no built-in 2FA. The easiest path is to install Solid Security (formerly iThemes Security) or Wordfence. Both include 2FA in the free version. After activation, go to Security → Settings → Two-Factor Authentication and enable it for the Administrator role.

These same plugins close a dozen more vulnerabilities out of the box:

• Solid Security: changes the login URL (/wp-admin → your unique slug), sets a login attempt limit, scans files for changes, blocks IPs after a series of failed logins, checks plugins and themes for known vulnerabilities.

• Wordfence: Web Application Firewall with automatically updated rules, malware scanner, brute-force protection, real-time traffic monitoring. It is especially good for cleaning an already hacked site: it finds backdoors, modified core files, hidden spam.

You only need ONE of them. On our projects, we install Wordfence + BBQ: the first provides a WAF and scanner, the second cuts off junk requests before they even get close.

Disable xmlrpc.php

XML-RPC is an interface for remote work with WordPress via mobile apps and trackbacks. Today, the vast majority of sites don't need it, yet it remains one of the most attacked points: bots use xmlrpc.php to brute-force passwords and conduct DDoS attacks.

You can disable it in two ways. The quick way, via a plugin: Solid Security does it in one click. The proper way, at the server level, in .htaccess:

1
<Files xmlrpc.php>
2
Order Deny,Allow
3
Deny from all
4
</Files>

Add this block to the root .htaccess and forget about xmlrpc. If you use the WordPress mobile app or external services that need XML-RPC, first check whether they work without it. In 2026, alternatives, the REST API with authentication, cover almost all scenarios.

Disable directory listing

Open вашсайт.com/wp-content/uploads/ in your browser. If you see a list of files, you have a problem. Directory listing shows your site structure to anyone who cares to look.

The solution: one line in .htaccess:

1
Options -Indexes

Also add an empty index.php to every suspicious directory: /wp-content/uploads/, themes, plugins that lack their own index.php.

Disable the file editor in the admin panel

WordPress ships with the ability to edit theme and plugin .php files right from the admin panel: Appearance → Theme File Editor and Plugins → Plugin File Editor. Convenient, until someone unauthorized gets into the admin panel. At that point it becomes a ready-made tool for uploading a shell.

Add one constant to wp-config.php:

1
define('DISALLOW_FILE_EDIT', true);

That is it. The editor disappears from the admin panel. Use FTP/SFTP for editing files, less convenient, but more secure.

Level 2: manual WordPress hardening

The following measures go a bit deeper: they require editing configuration files and understanding the server structure. The result is a site that bots bypass because they don’t see WordPress in it.

Update security salts

Salts, security keys and salts, eight lines in wp-config.php that encrypt authentication cookies. Changing them instantly logs everyone out, including a potential attacker with a stolen session.

Go to api.wordpress.org/secret-key/1.1/salt/, copy the generated block and replace the corresponding section in wp-config.php with it. Takes a minute. Do this whenever you suspect a compromise.

Change the database table prefix

By default all WordPress tables are named wp_posts, wp_users and wp_options. SQL injections are often tailored specifically to the standard prefix.

On a fresh install, specify a non-standard prefix in wp-config.php:

1
$table_prefix = 'wp83x_';

For an existing site changing it is harder: you need to rename tables in the database and update values in usermeta and options. Don’t attempt this without solid phpMyAdmin and SQL skills, the risk of taking the site down is too high.

Move wp-config.php above the web root

wp-config.php contains the database password and encryption keys. If the web server accidentally serves it as plain text, which happens during a botched PHP update, the attacker gets everything.

Solution: move wp-config.php one level above the site’s root directory, for example from /public_html/ to the hosting home folder. WordPress automatically looks for the config in the parent directory, the code won’t break.

Hide the WordPress version

The generator <meta name="generator" content="WordPress X.X.X"> in the page source is a gift for bots. They match the version against a database of known vulnerabilities and strike with precision.

Remove the generator via functions.php:

1
// Remove the WordPress generator meta tag from the page source code
2
function no_generator() {
3
    return '';
4
}
5
add_filter('the_generator', 'no_generator');

The no_generator() function returns an empty string instead of the standard version output. The the_generator filter intercepts the output of the meta tag and all its variations, for feeds, RSS and the REST API.

Also delete readme.html and liesmich.html from the installation root, they also expose the version. After a WordPress update these files can reappear, check once a month.

Configure HTTP security headers

HTTP response headers tell the browser how to handle content. Properly configured security headers block clickjacking, XSS and content spoofing.

A minimal set for WordPress, add these lines to .htaccess:

1
Header set X-Frame-Options "SAMEORIGIN"
2
Header set X-Content-Type-Options "nosniff"
3
Header set Referrer-Policy "strict-origin-when-cross-origin"
4
Header set X-XSS-Protection "1; mode=block"

The HTTP Headers plugin lets you do the same thing through the admin panel if you’d rather not touch the server configuration.

For advanced configuration use Content Security Policy. But note: an incorrect CSP breaks the admin panel, font loading and plugin functionality. Roll it out gradually, starting with Content-Security-Policy-Report-Only mode.

Restrict file permissions

Permissions, the last line of defense. If an attacker uploads a file but can’t execute it, the attack stalls.

Basic rules:

• Directories: 755, owner reads, writes, executes; group and others read and execute.
• Files: 644, owner reads and writes, others only read.
• wp-config.php: 400, only the owner reads.
• .htaccess: 444, read-only for everyone, if WordPress doesn’t edit it automatically.

Absolutely avoid 777. Yes, some plugins ask for 777 on wp-content/uploads/. Don’t give it. 755 on the folder and 644 on files inside is enough for media uploads.

What to do if the site is already hacked

A hack is discovered in different ways: a redirect to a casino, spam sending, a "This site may be hacked" banner in Google search results, a complaint from the hoster. The sequence of actions:

• Immediately change all passwords: WordPress admin, FTP/SFTP, database, hosting control panel. Start with the last one. If the hacker is in the hosting panel, they’ll just create a new admin.

• Restore the site from a backup made BEFORE the hack. A recent backup made after the compromise most likely contains a backdoor. If there’s no backup, next step.

• Install Wordfence and run a full scan. The plugin will find modified core files, suspicious code, hidden backdoors. Delete everything the scanner flagged, then replace the WordPress core with a fresh copy: the "Re-install" button under Dashboard → Updates.

• Check wp-content/uploads/ for .php files. They don’t belong there. Any .php in the uploads folder is almost certainly a shell.

Watch the video above, it breaks down typical WordPress security mistakes and how to fix them, from weak passwords to incorrect file permissions.

• Connect external monitoring. Sucuri, a cloud service with a WAF and a response team. The WAF filters traffic before it reaches the server. If a breach occurs, the Sucuri team cleans the site within hours. Pricing starts at $199/year for the basic plan with cleanup and monitoring. Not free, but when a site generates revenue, downtime costs more.

Make sure to register your site with Google Search Console. If Google detects malicious code, you will get a notification before the site drops out of search results.

Protection against ransomware: why backups solve everything

Ransomware encrypts site files and demands a ransom. WordPress sites are a frequent target: orders, customer databases, content. Losing everything overnight is a real scenario without a backup.

Three rules:

• Off-server backup. Cloud or a separate FTP. UpdraftPlus and Duplicator automate the offload.
• Firewall and scanner. Wordfence + BBQ block malicious file uploads at the request stage.
• Official sources only. The WordPress.org directory and developer sites with a reputation. No "free" themes from torrents.

Automatic file integrity monitoring

Server-side protection, not a one-off action. Assemble checks into a shell script on cron, once a day, results to email:

1
SITE_ROOT="/absolute/path/to/public_html"
2
 
3
find "$SITE_ROOT" -mtime -1 -name "*.php" \
4
    -printf '%TY-%Tm-%Td %TT\t%p\n' >> /tmp/file-changes.log
5
 
6
find "$SITE_ROOT" -mtime -7 -name "*.php" \
7
    | xargs grep -l -i "eval\|base64_decode\|iframe\|file_get_contents" \
8
    >> /tmp/suspicious-code.log
9
 
10
find "$SITE_ROOT/wp-content/uploads" -name "*.php" -print \
11
    >> /tmp/php-in-uploads.log
12
 
13
find /home -type d -perm 0777 >> /tmp/perms.log
14
find /home -type f -perm 0777 >> /tmp/perms.log
15
 
16
mailx -s "Webserver File Audit $(date +%F)" admin@example.com \
17
    < /tmp/suspicious-code.log

The script runs once a day via cron. The first block find -mtime -1 shows PHP files changed in the last 24 hours, the primary intrusion detector. The second looks for shell signatures: eval, base64_decode, hidden iframes. The third catches PHP in the uploads folder, where legitimate PHP never belongs. The fourth finds files and folders with 777 permissions. The result is sent to email. Proactive monitoring catches an intrusion at an early stage, before Google notices and bans the site from search results.

Sucuri: a cloud firewall for when you have no time to tinker

How it works: traffic passes through Sucuri's cloud proxy with a WAF, malicious requests are blocked before reaching the hosting. The site loads faster thanks to the CDN. Key capabilities: a WAF with real-time signatures, DDoS protection, automatic malware cleanup.

Plans start at $199/year. There is no free version, but the Sucuri scanner plugin checks files for changes without the WAF. For a commercial site, it is a justified investment. For a personal blog, Wordfence + BBQ is enough.

⁉️🤔 FAQ

Is WordPress itself secure?

The WordPress core is reviewed by hundreds of developers and security auditors. The problem is not the core; the problem is outdated plugins, themes from untrusted sources, and 123456 passwords. Regular updates plus a basic firewall provide sufficient protection for most sites.

Can I get by without security plugins?

You can, if you are willing to manually configure a firewall at the server level: iptables, mod_security, 7G/8G Firewall in .htaccess, track CVEs for every plugin, and write cron scripts for monitoring. For everyone else, installing Wordfence or Solid Security is an hour versus dozens of hours of manual work.

Are updates necessary if a firewall is in place?

Yes, absolutely. A firewall blocks attacks from the outside, but if a plugin with a known vulnerability is installed, sooner or later a vector will be found that the firewall does not catch. Updating all WordPress components is the foundation without which other measures work at half strength.

Which security plugin should I choose?

For minimal protection: BBQ Firewall, blocks malicious URL requests, zero configuration. For full protection: Wordfence, WAF, scanner, 2FA, brute force protection, all in the free version. The BBQ + Wordfence combo covers both layers without conflicts.

What about the REST API, should I disable it?

The REST API is needed by WordPress for the Gutenberg block editor, a number of plugins, and external integrations. Completely disabling it will break the admin panel. Instead, restrict access: leave only public endpoints for unauthenticated users. The REST API Toolbox plugin lets you flexibly configure access without surgical intervention.

How often should I scan the site for viruses?

Automatically, daily via cron scripts: checking for changed files, looking for .php in uploads. Manually, once a month: go into Wordfence, run a full scan, check the plugin list for abandoned ones. No updates for over a year, delete or replace.

Can I lose Google rankings because of a hack?

You can, and quickly. Google scans sites for malicious code and flags infected ones with a warning in search results. If the hack is not fixed within a few weeks, the site gets deindexed. Register your site in Google Search Console, and you will get a notification about the issue as soon as it is detected.

Will switching hosts help prevent hacks?

Partially. Quality hosting adds its own layers: account isolation, network monitoring, auto-updating PHP. But hosting does not protect against a leaky plugin you installed yourself, or the password qwerty. Security is a layer cake: hosting plus updates plus firewall plus access rights plus backups.

WordPress security: where to start today

The main rule of WordPress security is not to try to tackle everything in one sitting. Start with three steps:

• If there is no firewall, install BBQ Firewall. One minute.
• If there are no off-server backups, set up UpdraftPlus with cloud upload. Ten minutes.
• If 2FA is not enabled for administrators, enable it via Wordfence. Five minutes.

Then come back to the list above: disable xmlrpc, update salts, disable the file editor, configure security headers. One item a day, and in a week your site will be an order of magnitude better protected than it was yesterday.

What security measures are already working on your site? Let me know in the comments, I am curious to compare approaches.