WordPress powers a large share of the web, which makes it a frequent target for automated attacks and targeted intrusions. A compromised site can lead to data loss, reputation damage, and costly downtime. Understanding the most common attack vectors and applying layered defenses reduces risk dramatically.
Keep core, themes, and plugins up to date
Outdated software is the single largest entry point for attackers. The WordPress core team releases security patches regularly, and most reputable theme and plugin authors follow suit. Enable automatic updates for minor core releases, and schedule a weekly check for major versions, themes, and plugins. Before applying a major update, test it on a staging copy to avoid compatibility problems that could break functionality.
Use strong authentication
Weak passwords and reused credentials remain a top cause of account takeover. Require complex passwords for every user role, and enforce two‑factor authentication for administrators and editors. Plugins that add time‑based one‑time passwords or push notifications provide a low‑friction second factor. Disable XML‑RPC if it is not needed, because it allows credential‑stuffing attacks against the legacy API.
Limit login attempts and monitor activity
Brute‑force bots hammer login pages with thousands of guesses per minute. A simple limit — such as five failed attempts followed by a temporary lockout — stops most automated campaigns. Combine this with a log‑monitoring tool that alerts you to unusual patterns, like logins from new geographic locations or at odd hours. Reviewing audit logs weekly helps spot compromised accounts before they cause damage.
Harden the file system and configuration
File permissions that are too permissive let an attacker modify executable code. Set directories to 755 and files to 644, and ensure the wp‑config.php file is not world‑readable. Disable file editing from the dashboard by adding define('DISALLOW_FILE_EDIT', true); to wp‑config.php. Move the wp‑content directory outside the web root when possible, and restrict access to sensitive files such as .htaccess and wp‑config.php with server‑level rules.
Deploy a web application firewall
A web application firewall (WAF) inspects incoming traffic and blocks known malicious payloads before they reach WordPress. Cloud‑based services like Cloudflare or Sucuri provide rule sets that cover SQL injection, cross‑site scripting, and vulnerability scans. For self‑hosted environments, ModSecurity with the OWASP Core Rule Set offers comparable protection. Keep the rule set updated, and tune it to avoid false positives that could block legitimate users.
Regular backups and recovery planning
Even a well‑hardened site can be compromised through a zero‑day exploit or a supply‑chain attack on a trusted plugin. Automated off‑site backups taken daily — or more frequently for high‑traffic sites — ensure you can restore a clean state quickly. Store backups in a separate cloud account or physical media, and test restoration at least once per quarter. Document the recovery steps so any team member can execute them under pressure.
Common mistakes to avoid
- Using the default “admin” username.
- Leaving unused themes and plugins installed.
- Granting administrator rights to content editors.
- Ignoring security headers such as Content‑Security‑Policy.
- Relying solely on a single plugin for all protection.
Frequently Asked Questions (FAQs)
How often should I update WordPress core?
Apply minor security releases automatically. For major releases, test on a staging site first, then update production within a week of release.
Is two‑factor authentication required for every user?
At minimum, enforce it for administrators and editors. Contributors and subscribers can use it optionally, but requiring it for all roles adds a strong safety net.
What file permissions are safest for a typical installation?
Directories 755, files 644, and wp‑config.php 600. Adjust only if a specific plugin documents a different requirement.
Can a web application firewall replace other security measures?
A WAF is an important layer, but it cannot stop attacks that originate from compromised credentials or vulnerable code already present on the server. Use it together with updates, strong authentication, and hardening.
How do I verify that my backups are usable?
Restore a backup to a temporary environment and confirm that the site loads, the database connects, and critical plugins function. Perform this test quarterly.
What should I do if I suspect a breach?
Immediately take the site offline or enable maintenance mode, change all passwords, revoke API keys, and restore from the most recent clean backup. Then audit logs to determine the entry point and apply additional hardening.
