WordPress’s popularity is a double-edged characteristic. The same broad adoption that gives it its vast plugin ecosystem and developer community also makes it the most targeted CMS by automated vulnerability scanning tools. A default WordPress installation exposed to the internet will receive probing attempts within hours. Understanding which hardening measures provide real security value โ versus which are security theatre โ is essential for anyone responsible for a WordPress site.
Keep Core, Themes, and Plugins Updated โ Without Exception
The majority of successful WordPress breaches exploit known vulnerabilities in outdated software. WordPress core auto-updates for minor security releases by default, but plugins and themes do not. Every plugin in your installation is a potential attack surface, and popular plugins with large install counts receive targeted exploit development as soon as a vulnerability is disclosed.
Enable automatic updates for trusted plugins, audit your plugin list regularly to remove anything no longer actively maintained, and treat a plugin with no updates in two years as a security liability regardless of whether a known vulnerability exists yet.
Limit Login Attempts and Use Strong Authentication
Brute force attacks against wp-login.php are constant background noise for any public WordPress installation. Limiting login attempts (via a plugin or server-level rate limiting) eliminates the most unsophisticated of these attacks. More importantly, require two-factor authentication for all admin accounts โ a compromised password alone is not sufficient to gain access.
Consider moving or obscuring wp-login.php via a login URL change. This is not a real security measure on its own, but it does eliminate the vast majority of automated brute force traffic that targets the default login path, which reduces server load and log noise.
Database Security: Prefix Changes and Privileges
The default WordPress database table prefix is wp_. Automated SQL injection exploits frequently target this prefix when attempting to enumerate or modify WordPress data. Changing the prefix during installation is a low-cost, low-impact step that eliminates a category of automated attack. Changing it after installation requires more care but is achievable with a plugin.
The WordPress database user should have only the permissions it needs for normal operation: SELECT, INSERT, UPDATE, DELETE. It should not have DROP, ALTER, or CREATE privileges that would allow an attacker to modify the database structure if they obtain SQL injection execution.
File System Permissions and Direct File Access
WordPress core files should not be world-writable. The wp-config.php file deserves particular attention: it contains database credentials and security keys and should be readable only by the web server user. Moving it one directory above the web root eliminates direct HTTP access to it as an additional layer.
Disable file editing via the WordPress admin by adding define(‘DISALLOW_FILE_EDIT’, true) to wp-config.php. This prevents an attacker who has gained admin access from using the theme or plugin editor to execute arbitrary PHP on your server.
Web Application Firewall and Malware Scanning
A web application firewall (WAF) โ whether implemented at the server level (ModSecurity), via a CDN/proxy (Cloudflare), or through a WordPress security plugin โ provides real-time filtering of malicious requests before they reach your application. Combined with regular malware scanning that checks file integrity against known-good WordPress file hashes, these measures catch both attempted exploits and successful compromises early.
Security is not a one-time configuration; it is an ongoing practice. A site hardened two years ago may be fully exposed today because of a plugin that stopped being maintained, an access credential left unchanged, or a hosting environment that is no longer receiving security updates. Regular audits matter as much as the initial hardening.
