How to Protect WordPress: A Practical Security Guide

WordPress powers roughly 43% of all websites on the internet. That popularity makes it a target. Automated bots scan for WordPress installations around the clock, probing for outdated plugins, weak passwords, and misconfigured servers. Most attacks aren’t personal. They’re opportunistic scripts looking for the path of least resistance.

The good news is that securing WordPress isn’t complicated. Most successful attacks exploit well-known weaknesses that are straightforward to fix. Updates, strong passwords, server-level protections, and a few smart configuration changes will put your site ahead of the vast majority of WordPress installations out there.

Here’s what actually matters.

Keep everything updated#

This is the single most important thing you can do. WordPress core, themes, and plugins all receive security patches, and running outdated versions is how most sites get compromised.

The pattern repeats constantly: a vulnerability is discovered in a plugin, a patch is released, and the sites that update promptly are fine. The sites that don’t become targets. In 2019, the Social Warfare plugin had a critical flaw that allowed attackers to take over entire websites. The fix was available quickly, but sites that hadn’t updated kept getting hit for weeks afterward. The same story plays out with dozens of plugins every year.

What to do:

• Enable automatic updates for WordPress core (minor releases update automatically by default; consider enabling auto-updates for major releases too)
• Enable auto-updates for plugins and themes where possible
• Check for updates at least weekly if you prefer manual control
• Remove plugins and themes you’re not actively using. Deactivated plugins can still be exploited if they contain vulnerabilities

Don’t assume that a plugin is safe because it’s popular. Popularity means more users, but it also means more attackers examining the code for weaknesses.

Use strong passwords and manage user access#

Weak passwords are the other half of the equation. Brute force attacks cycle through common passwords at scale, and “admin/password123” is tried on every WordPress site, every day.

Password basics:

• Use a password manager (Bitwarden, 1Password, or KeePass) to generate and store unique passwords for every account
• WordPress passwords should be at least 16 characters with mixed case, numbers, and symbols
• Never reuse passwords across sites. A breach on one service exposes every account sharing that password

User management:

• Don’t use “admin” as a username. It’s the first thing bots try
• Assign the minimum role needed. Content writers don’t need Administrator access. Use Author or Editor roles instead
• Remove accounts for people who no longer need access. Forgotten accounts with stale passwords are easy targets
• Review user accounts periodically. If you see accounts you don’t recognize, investigate immediately

Enable two-factor authentication#

Two-factor authentication (2FA) makes stolen passwords useless. Even if an attacker has your password, they can’t log in without the second factor, typically a time-based code from an app on your phone.

Setting it up:

Install a 2FA plugin like WP 2FA, Two-Factor, or Wordfence Login Security. Configure it to require 2FA for all administrator and editor accounts at minimum. Users install an authenticator app (Google Authenticator, Authy, or any TOTP-compatible app) and scan a QR code during setup. From that point on, every login requires both the password and a 6-digit code from the app.

For teams, enforce 2FA for all users with publishing or administrative permissions. The slight inconvenience is worth it. 2FA alone would have prevented the majority of WordPress account compromises over the past several years.

Protect the login page#

The default WordPress login page at /wp-login.php is public and well-known. Every bot on the internet knows exactly where to find it. While strong passwords and 2FA protect the authentication itself, reducing exposure to the login page adds another layer.

Limit login attempts. Plugins like Limit Login Attempts Reloaded or Wordfence can block an IP after a set number of failed attempts. This slows down brute force attacks significantly.

Consider IP-based restrictions. If your team accesses the admin from known IP addresses, you can restrict wp-login.php and /wp-admin/ to those IPs at the server level. We cover this in detail in our guide on restricting WordPress admin access by IP address.

Disable XML-RPC if you don’t need it. The xmlrpc.php endpoint is a legacy interface that many bots exploit for brute force attacks and DDoS amplification via pingback abuse. Unless you use the WordPress mobile app, Jetpack, or a specific tool that requires XML-RPC, block it. On Hostney, this is a one-click toggle in your WordPress security settings; no plugin needed.

Block user enumeration. Attackers query the WordPress REST API at /wp-json/wp/v2/users to discover valid usernames before attempting password attacks. Blocking this endpoint prevents that reconnaissance step. Again, Hostney provides this as a server-level toggle.

Set up a web application firewall#

A Web Application Firewall (WAF) inspects incoming HTTP requests and blocks those that match known attack patterns: SQL injection, cross-site scripting (XSS), file inclusion, and other common exploits.

Plugin-based WAFs like Wordfence and Sucuri Security run inside WordPress. They catch a wide range of attacks but consume PHP resources since every request passes through the plugin before reaching your content.

Server-level WAFs run at the web server layer (before PHP executes), which is more efficient and harder for attackers to bypass. ModSecurity with the OWASP Core Rule Set (CRS) is the industry standard for server-level WAF protection.

Hostney runs ModSecurity with the OWASP CRS on every server. You can configure it per website through the control panel: choose between blocking mode (actively stops attacks) or detection mode (logs threats without blocking, useful for testing). You can also adjust the anomaly scoring threshold and add rule exclusions for specific paths if a legitimate plugin triggers false positives.

If your host doesn’t provide a server-level WAF, a plugin-based WAF is absolutely better than nothing. Wordfence is the most widely used option and does a solid job.

Protect files and data#

A few file-level protections go a long way:

Block PHP execution in the uploads directory. WordPress stores media uploads in /wp-content/uploads/ . If an attacker manages to upload a malicious PHP file through a plugin vulnerability, you don’t want the server to execute it. Blocking PHP execution in that directory neutralizes the threat even if the file gets uploaded. On Hostney, this is a server-level toggle. On other hosts, you can add this to your Nginx or Apache configuration manually.

Secure wp-config.php. This file contains your database credentials and authentication keys. It should never be publicly accessible. On most properly configured servers it isn’t, but verify by trying to access yourdomain.com/wp-config.php in a browser. You should get a 403 or blank page, not the file contents.

Use SSL/TLS everywhere. Your site should load exclusively over HTTPS. This encrypts data between your visitors’ browsers and your server, protecting login credentials, form submissions, and session cookies from interception. Hostney includes free Let’s Encrypt SSL certificates with automatic renewal on every plan. To learn more, read our guide on how SSL certificates work.

Keep regular backups. Backups don’t prevent attacks, but they limit the damage. When the popular File Manager plugin had a critical vulnerability in 2020 that led to mass site infections, the sites that recovered fastest were the ones with recent backups. Store backups off-server (a separate server, cloud storage, or your hosting provider’s backup system) so they’re available even if your web server is compromised.

To learn more, read our guide on how to back up WordPress manually.

Scan for malware regularly#

Malware can sit on a WordPress site for weeks before anyone notices. It might redirect visitors to spam sites, inject hidden links for SEO manipulation, send phishing emails from your server, or quietly mine cryptocurrency using your server’s resources. Regular scanning catches infections before they cause serious damage.

Plugin-level scanning: Wordfence and Sucuri Security both scan WordPress files against known clean versions and flag modifications. They also check for known malware signatures, backdoors, and suspicious code patterns. Run scans at least weekly.

Server-level scanning: ClamAV is an open-source antivirus engine that scans files at the server level, outside of WordPress entirely. This catches threats that plugin-based scanners might miss, especially if the malware has modified WordPress core files in ways that prevent plugins from running properly.

Hostney runs ClamAV on every server with automatic signature updates. Detected threats appear in your malware dashboard with incident details, severity ratings, and resolution status. Server-level scanning works even if WordPress itself is compromised, which is precisely when you need it most.

Implement Content Security Policies#

Content Security Policy (CSP) headers tell browsers which sources of content are trusted on your site. If an attacker manages to inject a script tag pointing to their server, a properly configured CSP will prevent the browser from executing it.

CSP is one of the most effective defenses against cross-site scripting (XSS) attacks, but it requires careful configuration. Start with a report-only policy to see what would be blocked without actually breaking anything:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted-cdn.com;

Once you’ve verified that all legitimate resources are covered, switch to enforcement mode. Be prepared to allow sources for analytics scripts, font providers, embedded videos, and any third-party services your site uses.

Plugins like HTTP Headers or security-focused plugins with CSP support can help manage these headers without editing server configuration directly.

Choose secure hosting#

Your hosting environment is the foundation everything else sits on. A well-secured WordPress installation on a poorly configured server is still vulnerable.

What to look for in a WordPress host:

User isolation. On shared hosting, your site runs alongside other customers’ sites on the same server. Without proper isolation, a compromised site could potentially access files belonging to other accounts. Hostney uses containerized isolation with Podman, giving each account its own isolated environment with dedicated CPU, memory, and I/O limits enforced through systemd cgroups. One compromised account cannot see or access another account’s files, processes, or data.

Server-level rate limiting. Request rate limits at the web server layer stop automated attacks before they reach WordPress. Hostney applies WordPress-aware rate limiting by default: POST requests are limited to 30 per minute (with burst allowance), per-IP limits cap at 2 requests per second, and logged-in WordPress users automatically bypass rate limits so normal admin work isn’t interrupted.

Automated bot detection. Beyond rate limiting, behavioral analysis catches sophisticated attacks that stay under simple rate thresholds. Hostney’s bot detection system scores every IP on 26 signals including request patterns, login endpoint targeting, browser fingerprinting, and cookie behavior. Suspicious IPs are challenged with a proof-of-work puzzle that real browsers solve in seconds but automated scripts can’t handle. IPs that score high enough are banned across all servers automatically.

Firewall and WAF. ModSecurity with OWASP CRS, fail2ban for intrusion prevention, and kernel-level network hardening (SYN flood protection, reverse path filtering, connection tracking limits) should all be in place. These aren’t features you should have to configure yourself.

Automatic SSL. Free SSL certificates with automatic renewal. If your host charges extra for SSL or makes you manage renewals manually, that’s a red flag.

DDoS mitigation. Multi-tiered rate detection, proof-of-work challenges, real-time IP scoring, and cross-server ban propagation. Hostney provides all of this at the origin server level, included in every plan.

Monitor and respond to incidents#

Security isn’t something you set up once and forget. Ongoing monitoring catches problems early, and having a response plan means you know exactly what to do when something goes wrong.

Monitor your site:

• Review your hosting provider’s security dashboard regularly. Hostney’s firewall dashboard shows threat scores, blocked IPs, attack patterns, and web attack statistics with per-IP signal breakdowns
• Check your WordPress audit logs for unexpected user account changes, plugin installations, or setting modifications
• Set up uptime monitoring so you’re notified immediately if your site goes down (which can indicate an ongoing attack or a compromised server)

Have an incident response plan:

• Know how to access your server outside of WordPress (SSH, hosting control panel file manager) in case WordPress itself is compromised
• Know where your backups are stored and how to restore them
• Know how to put your site into maintenance mode quickly to stop active damage
• If you’re on Hostney, lockdown mode challenges all visitors with proof-of-work, giving you time to investigate without taking the site fully offline. You can exempt your own IP, specific countries, or verified search engine bots while the lockdown is active

Security checklist#

Check out WordPress.org security documentation for additional reference.

Try Hostney web hosting free for 14 days. Every plan includes containerized isolation, ModSecurity WAF, automated bot detection, free SSL, malware scanning, and WordPress-specific security controls built in.