WordPress powers roughly 43% of the web. That statistic is frequently cited as evidence of the platform’s success. It is equally useful as an explanation for why WordPress sites are among the most consistently attacked targets on the internet. When a single platform accounts for nearly half of all websites, exploiting it at scale becomes economically rational. Automated scanners probe for known misconfigurations around the clock. The question is not whether your WordPress site will be targeted — it will be — but whether the configuration you are running makes exploitation trivially easy or genuinely difficult. Most default installations fall firmly in the first category. WordPress security misconfigurations fix is not a one-time task; it is an ongoing posture. Here is what that posture actually looks like.
The Default Install Is Not Secure
A vanilla WordPress installation ships with settings optimized for ease of use, not defense. That is a deliberate tradeoff — WordPress serves millions of casual users who would not know what XML-RPC is, let alone why it presents an attack surface. The problem arises when developers and site operators deploy WordPress without revisiting those defaults with a security lens. Several of those defaults are actively harmful in a production context.
Directory listing is enabled by default in many web server configurations that accompany WordPress installs. Without an Options -Indexes directive in your .htaccess or Nginx equivalent, visiting a path like /wp-content/uploads/2024/ in a browser may return a full listing of every file in that directory. For an attacker doing reconnaissance, this is free intelligence about your file structure, plugin versions, and uploaded assets.
Debug mode is a similar case. WP_DEBUG defaults to false, but it is enabled in countless production sites because a developer turned it on during troubleshooting and never turned it off. With WP_DEBUG_DISPLAY set to true, PHP errors — including file paths, database queries, and configuration details — print directly to the page. This is not a theoretical concern; it is information an attacker can use to identify exploitable plugins and understand your server layout.
These are not exotic attack vectors. They are the kind of basic misconfigurations that Shodan, WPScan, and automated exploit kits check for as a first pass.
The Login Surface Problem
WordPress ships with its admin login at /wp-login.php, and that path is known by every automated scanner in existence. Bots continuously cycle through credential lists against this endpoint. The fact that it is predictable matters more than most operators realize: if an attacker knows exactly where to send requests, the only variable is whether they can authenticate. Any site with a weak or reused admin password is one credential leak away from full compromise.
The standard response is to move or restrict the login page. Plugins like WPS Hide Login let you change the login URL to an arbitrary path, which dramatically reduces automated traffic to that endpoint. This is not security through obscurity in the pejorative sense — it is friction, and friction has real value against automated attacks. Combine it with rate limiting (the Limit Login Attempts Reloaded plugin, or server-level rate limiting via Nginx’s limit_req_zone directive) and you eliminate the majority of brute-force exposure.
Two-factor authentication belongs in this stack unconditionally. The WP 2FA or Google Authenticator plugins both support TOTP-based 2FA for admin accounts. Given that credential stuffing is the dominant initial access method across web applications, 2FA is the single control with the highest return on investment. An attacker with a valid password cannot log in without the second factor. That breaks the most common attack chain entirely.
One configuration failure that persists embarrassingly often: the default admin username. WordPress historically defaulted to the username “admin,” and a substantial fraction of sites still use it. Credential lists always include “admin” as a top candidate. If your administrator account username is “admin,” change it. The cleanest method is creating a new administrator account with a different username, reassigning all content to it, then deleting the original. Some operators use the WP-CLI command wp user update 1 --user_login=newusername, though this requires direct database consistency checks afterward.
XML-RPC: A Legacy Interface That Should Be Disabled
XML-RPC was WordPress’s remote publishing API before the REST API existed. It allowed tools like MarsEdit and mobile apps to post content without using the browser admin panel. Today, the REST API handles those use cases more cleanly. XML-RPC is largely unnecessary, yet it remains enabled by default.
The security problem with XML-RPC is not just credential brute-forcing, though that is real: XML-RPC supports a system.multicall method that allows multiple method calls in a single HTTP request, meaning an attacker can test hundreds of username-password combinations in a single request, effectively bypassing naive per-request rate limiting. The DDoS amplification vector is also worth noting — WordPress sites with XML-RPC enabled have been weaponized as unwitting participants in pingback flood attacks against third-party targets.
Unless you have a specific, verified need for XML-RPC (legacy mobile publishing workflows, Jetpack in some configurations), disable it. The most reliable method is a server-level block rather than a plugin — plugins can be disabled, but a server rule cannot be undone by a compromised admin account:
For Apache, add
Deny from allinside aFiles xmlrpc.phpblock in your.htaccess. For Nginx, addlocation = /xmlrpc.php { deny all; }to your server block. This blocks the endpoint before WordPress even loads, saving processing overhead in addition to reducing attack surface.
Plugin Vulnerabilities: The Actual Attack Surface
Sucuri’s annual hacked website reports consistently attribute roughly 90% of WordPress compromises to vulnerable plugins and themes, not to WordPress core. This figure is important to internalize: hardening WordPress core while running outdated plugins is like reinforcing a vault door while leaving a window open.
The plugin vulnerability lifecycle is predictable. A researcher or attacker discovers a vulnerability in a popular plugin — cross-site scripting, SQL injection, arbitrary file upload, unauthenticated privilege escalation. If a CVE is filed and a patch is released, the patch is indexed publicly. Automated scanners begin probing for the vulnerable version almost immediately. Sites that have not updated within the first 48-72 hours of a patch release are at elevated risk, because the vulnerability is now public knowledge.
The WPScan Vulnerability Database and Patchstack both track plugin CVEs. Running wpscan --url yoursite.com --api-token YOUR_TOKEN will enumerate installed plugins and flag any with known CVEs against their installed versions. This is the minimum viable external audit — do it regularly, not just once. WPScan’s free API tier allows 25 API requests per day, which is sufficient for routine scanning of a small portfolio.
Concrete actions that reduce plugin attack surface:
- Delete unused plugins, not just deactivate them. Deactivated plugins still exist on the filesystem and can be targeted by file inclusion attacks.
- Enable automatic updates for plugins you do not need to test before updating. For production sites running custom integrations, set up a staging environment where you can validate updates before deploying. The risk of an unreviewed update breaking functionality is almost always lower than the risk of staying on a vulnerable version.
- Audit plugin age and maintenance status. A plugin with its last update two years ago and no active development is a liability. Check the WordPress plugin repository — it shows when the plugin was last updated and whether it has been tested against recent WordPress versions. Abandoned plugins are frequently targeted because their vulnerabilities will never be patched.
- Be ruthless about the number of plugins you run. Each plugin is a potential vulnerability. A site running 40 plugins has a substantially larger attack surface than a site running 15. Evaluate whether each plugin is genuinely necessary or whether its function could be handled in code.
wp-config.php Hardening: The Checklist
wp-config.php is the most sensitive file in a WordPress installation. It contains database credentials, security keys, and configuration switches that fundamentally affect the security posture of the site. Getting it right requires more than just setting a strong database password.
Security keys and salts. WordPress uses these constants to hash passwords and session tokens. The defaults in a fresh install are placeholders. Generate proper values at api.wordpress.org/secret-key/1.1/salt/ and paste them into your config. If you have reason to believe your site has been compromised and want to invalidate all active sessions, regenerating these salts forces every logged-in user to reauthenticate.
Debug mode off in production. This should be explicit in your config: define( 'WP_DEBUG', false );. If you need to log errors without displaying them, use define( 'WP_DEBUG_LOG', true ); with define( 'WP_DEBUG_DISPLAY', false ); and ensure the log file is outside the web root or access-restricted via your web server configuration.
Change the table prefix. The default wp_ prefix is known. SQL injection exploits frequently reference it by name. Changing it to something like site4k2_ does not prevent SQL injection — that requires parameterized queries in the code — but it raises the specificity required for a successful generic exploit. For existing sites, changing the prefix requires a database migration; tools like WP-CLI’s wp search-replace can help, but test thoroughly on a staging copy first.
Disable file editing from the admin panel. WordPress ships with a theme and plugin editor accessible from the admin dashboard. If an attacker gains admin credentials, this editor provides immediate arbitrary PHP execution. There is no good reason to have it enabled in production: define( 'DISALLOW_FILE_EDIT', true );. Pair it with define( 'DISALLOW_FILE_MODS', true ); if you want to prevent plugin and theme installation from the admin panel entirely — appropriate for sites where updates are managed through a deployment pipeline rather than through the WordPress dashboard.
Move wp-config.php above the web root. WordPress will look for wp-config.php one directory above the installation path if it is not found in the web root. Moving it there means a misconfigured PHP parser — one that serves PHP files as plaintext — cannot expose your database credentials directly over HTTP. This is a defense-in-depth measure, not a primary control, but the cost is zero and the benefit is real.
File Permissions: The 777 Problem
Permissions set to 777 (world-writable) on WordPress files or directories are a persistent problem in tutorial land. The instruction “chmod 777 if you have permission errors” appears in a staggering number of WordPress guides and Stack Overflow answers. It solves the immediate problem by removing all access controls, which is exactly the wrong tradeoff.
Correct permissions for a WordPress installation on a typical shared or VPS host:
| Target | Correct Permission | Rationale |
|---|---|---|
WordPress files (.php, etc.) |
644 | Owner read/write, world read only |
| WordPress directories | 755 | Owner full, group/world traverse and read |
wp-config.php |
600 or 640 | No world read; only owner (and group if needed) |
wp-content/uploads |
755 | Web server needs write for uploads; never 777 |
The uploads directory is where most permission confusion originates. The web server process needs to write uploaded files. The fix is not 777 — it is ensuring the uploads directory is owned by or writable by the web server user (www-data on Debian/Ubuntu systems). chown -R www-data:www-data wp-content/uploads with 755 permissions achieves this cleanly.
Additionally, no PHP file should ever be executable by the web server in the uploads directory. A malicious uploaded file with a .php extension should not be interpretable as code. Add this to your .htaccess inside the uploads directory: php_flag engine off (Apache) or the Nginx equivalent location ~* \.php$ { deny all; } scoped to the uploads path.
Security Headers: What Most WordPress Sites Are Missing
HTTP security headers are server-level instructions that tell browsers how to handle the site’s content. They are not WordPress-specific, but they are systematically absent from most WordPress deployments. A site without proper security headers is vulnerable to entire classes of client-side attacks that headers would prevent.
The headers worth implementing, in order of impact:
- Content-Security-Policy (CSP). Defines which sources of scripts, styles, images, and other resources the browser should trust. A properly configured CSP prevents the overwhelming majority of XSS attacks from being exploitable — even if malicious JavaScript is injected, it cannot load from unauthorized sources or exfiltrate data. CSP is the hardest header to configure correctly because WordPress’s plugin ecosystem uses inline scripts extensively. A reasonable starting point is a report-only policy (
Content-Security-Policy-Report-Only) to identify violations before enforcing. - X-Frame-Options: SAMEORIGIN. Prevents your site from being embedded in an iframe on another domain. This blocks clickjacking attacks where an attacker overlays your login page with transparent elements to harvest credentials. The modern equivalent is
Content-Security-Policy: frame-ancestors 'self', but X-Frame-Options remains necessary for legacy browser support. - X-Content-Type-Options: nosniff. Prevents browsers from MIME-sniffing responses away from the declared content type. Without this, a browser might execute an uploaded file as JavaScript even if it is served with a non-script content type.
- Strict-Transport-Security (HSTS). Once you are running HTTPS (which you should be — Let’s Encrypt makes this free and automated), HSTS instructs browsers to refuse HTTP connections to your domain entirely. A typical starting value:
max-age=31536000; includeSubDomains. Do not addpreloaduntil you are confident your entire domain and subdomains are reliably HTTPS. - Referrer-Policy: strict-origin-when-cross-origin. Controls how much referrer information is included when navigating to external sites. The default browser behavior can leak admin URLs and session-related query parameters to third-party analytics.
- Permissions-Policy. Restricts access to browser APIs like the camera, microphone, and geolocation. For most WordPress sites, these features are unnecessary and should be explicitly blocked:
Permissions-Policy: camera=(), microphone=(), geolocation=().
The securityheaders.com scanner grades your current header configuration and explains each missing header. Run it against your site before and after implementing these changes. A score below B represents meaningful, fixable exposure.
Backup Strategy: What “Having Backups” Actually Means
Every WordPress operator will tell you they have backups. A meaningful fraction of them will discover, at the worst possible moment, that their backups are incomplete, untested, inaccessible, or co-located with the compromised server. A backup you cannot restore from in a reasonable timeframe is not a backup — it is the illusion of a backup.
A functional backup strategy requires four properties working together:
Automation. Manual backups are not executed consistently under pressure. Use a solution that runs on a schedule without human intervention. UpdraftPlus, WP Time Capsule, and BackWPup are established plugins; for managed hosts, Kinsta and WP Engine include automated daily backups. The frequency should match your content update cadence — a site publishing ten posts a day needs different backup scheduling than a static brochure site.
Off-site storage. A backup stored on the same server as the WordPress installation is worthless if the server is compromised or the hosting account is deleted. Configure your backup tool to push copies to an independent destination: Amazon S3, Backblaze B2, or Google Drive. Backblaze B2 costs approximately $0.006 per GB per month — for a 10 GB site backup set, that is $0.06/month for genuine off-site redundancy. The cost argument for keeping backups on the same server does not exist.
Tested restores. Backups are a hypothesis about what will happen in a crisis. Test the hypothesis. At minimum, quarterly: download a backup, spin up a staging environment, and restore from it. Verify that the site loads correctly, that database content is intact, and that the restore process takes an acceptable amount of time. Discovering during an incident that your backup files are corrupted, that the restore procedure is undocumented, or that a full restore takes 14 hours is not an acceptable outcome.
Retention depth. A single daily backup retained for 7 days is insufficient for a sophisticated attack. Some compromises — particularly database injections and malware implants — are not discovered immediately. The malicious code may have been present for 30 days before anyone noticed. Your backup retention needs to extend far enough back to reach a clean state. Keep 30-day retention at minimum; 90-day retention for any site handling sensitive user data.
Security Plugins: Useful, Not Sufficient
Wordfence and Sucuri are the dominant WordPress security plugins. Both are genuinely useful. Neither is a substitute for the configuration work described in this piece, and treating them as such is a common and costly mistake.
Wordfence’s web application firewall (WAF) operates in WordPress PHP context, which means it runs after WordPress has already loaded. A server-level vulnerability or a PHP execution bypass can compromise the system before Wordfence has any visibility into it. This is not a criticism unique to Wordfence — it is an architectural constraint of any security plugin operating at the application layer. Sucuri’s cloud-based WAF (which routes all traffic through Sucuri’s network before it reaches your server) does not have this limitation, but it is a paid feature and introduces a DNS dependency.
What Wordfence does well: file integrity monitoring against the WordPress core and plugin repositories, malware scanning, brute-force protection for wp-login.php, and alerting on unexpected file changes. These are valuable. The file integrity monitoring in particular catches compromises that other monitoring would miss — a backdoor injected into a theme file, for example, shows up as an unexpected modification in a known file.
The correct mental model: security plugins handle detection and some surface-level blocking. Configuration hardening — server permissions, headers, wp-config.php settings, XML-RPC disabled — handles prevention at layers the plugins cannot reach. You need both, not one in place of the other.
Monitoring: What to Watch For
Security is not a state you achieve and then maintain passively. Effective WordPress security requires ongoing observation. Three monitoring categories provide the most signal for the effort invested.
File integrity monitoring. Track changes to PHP files, .htaccess, and configuration files. Wordfence does this at the plugin level; on the server side, tools like AIDE (Advanced Intrusion Detection Environment) or simple cron-driven md5sum comparisons against a known-good baseline work for smaller setups. Any modification to a core WordPress file that you did not initiate through an update is a serious indicator of compromise.
Failed login alerting. A sudden spike in failed logins against /wp-login.php or /wp-json/ endpoints indicates an active brute-force campaign. Your server access logs and Wordfence’s login security module both surface this. The threshold that should trigger an alert varies by site, but an order-of-magnitude increase in authentication failures is always worth investigating.
Admin user auditing. Periodically verify the list of users with administrator privileges. Backdoor installations frequently create a new administrator account with an inconspicuous username. A query like wp user list --role=administrator via WP-CLI, or a direct database query against wp_usermeta for the wp_capabilities field, surfaces any unauthorized admin accounts. If you find an account you did not create, you have an active compromise — the priority becomes incident response, not further hardening.
Automated monitoring reduces the human attention required to maintain acceptable visibility. Services like ManageWP and MainWP aggregate monitoring across multiple WordPress sites, surfacing update needs, uptime alerts, and security scan results in a single dashboard. For agencies or developers managing a site portfolio, the overhead reduction is significant.
Where to Start
The full scope of WordPress security hardening can feel paralyzing, particularly for operators managing multiple sites or inheriting existing installations with unknown configuration histories. The practical prioritization looks like this.
In the first 24 hours: disable XML-RPC at the server level, set WP_DEBUG to false, block directory listing, update all plugins to current versions, and enable 2FA on all administrator accounts. These five actions address the highest-probability attack vectors with the least implementation complexity.
In the first week: harden wp-config.php with correct debug settings, regenerated salts, and file editing disabled. Correct file permissions across the installation. Implement security headers — even a partial set covering X-Frame-Options, X-Content-Type-Options, and HSTS is substantially better than nothing. Set up automated off-site backups with a tested restore process.
Ongoing: run WPScan regularly against your installation. Audit your plugin list quarterly and remove what you are not actively using. Review admin user lists after any incident or major personnel change. Monitor file integrity and authentication logs for anomalies.
The threat landscape against WordPress is not static. New vulnerabilities are disclosed constantly. The sites that remain uncompromised are not the ones that completed a hardening checklist once — they are the ones that treated security as a continuous operational discipline, not a project with a completion date. That mindset shift, more than any individual configuration change, is the actual foundation of a defensible WordPress deployment.