WordPress security hardening: the checklist that matches real attacks
TL;DR: WordPress compromises are overwhelmingly opportunistic rather than targeted. Automated scanners sweep the internet looking for known vulnerabilities in outdated plugins and for weak credentials, and they find sites indiscriminately. Nobody chose you.
That changes what hardening should prioritise. The outermost layer, keeping plugins updated and deleting the ones you do not use, prevents more real compromises than every clever configuration tweak combined. Hiding your login URL is not security. Patching the plugin with a published vulnerability is.
How WordPress sites actually get compromised
Understanding the attack pattern is what makes hardening efficient rather than exhausting.
Vulnerable plugins and themes are by a wide margin the leading cause. A vulnerability is published, an exploit is automated within days, and scanners begin sweeping for sites running the affected version. The site owner had weeks or months to patch and did not.
Note what this means: the vulnerability was public and fixed before you were attacked. The compromise was a patching failure, not a sophisticated intrusion.
Weak or reused credentials come second. Brute forcing against wp-login.php is continuous and cheap. Credential stuffing, using passwords leaked from unrelated breaches, is more effective still because password reuse is common.
Outdated core matters but less than plugins, partly because WordPress auto-updates minor releases by default.
Compromised developer machines stealing saved FTP credentials from editors.
Hosting-level issues, including cross-contamination between poorly isolated sites on the same account.
The pattern across all five: automated, indiscriminate, and exploiting known problems. Defending against a targeted attacker is a different and much harder discipline that most small businesses do not need. Defending against automated sweeps is achievable and largely a matter of hygiene.
Layer one: update and plugin discipline
The highest-value layer, and the least interesting, which is why it gets neglected.
Update plugins and themes promptly. Not eventually. The window between a vulnerability being published and being exploited at scale is short. Enable automatic updates for plugins you trust, and check weekly for the rest.
The objection is that updates break things. That is what staging is for, and the risk of an update breaking a layout is smaller than the risk of running a plugin with a published remote code execution flaw.
Delete plugins you do not use. Deactivating is not enough. Deactivated plugin files remain on disk and remain executable if reachable directly, and several notable WordPress vulnerabilities have been exploitable in deactivated plugins.
Go through your plugin list and remove anything you cannot justify. Most sites can drop several immediately.
Avoid abandoned plugins. Check the last update date. A plugin untouched for two years will not receive a patch when a vulnerability is found, and unmaintained plugins are a common vector.
Be careful about sources. Nulled or pirated premium plugins are a well-established malware distribution channel. The backdoor is the point of the free version.
Keep core updated. Minor releases apply automatically by default; leave that on. Apply major releases within a reasonable window after testing.
Keep PHP updated. Running an end-of-life PHP version means no security patches at the language level, and it is one of the more common findings on neglected sites.
If you only do this layer, you have addressed the majority of realistic risk.
Layer two: authentication
Second in impact, and mostly free.
Unique, strong passwords on every account. Password reuse is what makes credential stuffing work. A password manager makes this trivial and there is no good reason not to use one.
Two-factor authentication on all administrator accounts. This is the single most effective control against credential-based attacks, because a stolen password alone becomes useless. Every serious security plugin offers it, and app-based TOTP is preferable to SMS.
Audit who has administrator access. Most sites have more admins than necessary: a developer from two years ago, an agency that no longer works with you, a staff member who left. Review the user list and downgrade or remove anyone who does not need the role today.
Use appropriate roles. A content writer needs Author or Editor, not Administrator. Role discipline limits what a compromised account can do.
Limit login attempts. Rate limiting or temporary lockout after repeated failures blunts brute forcing and reduces log noise substantially.
Disable XML-RPC if unused. It is a common brute-force target because it allows many authentication attempts in a single request. Some tools still require it, so check before disabling.
Remove the default admin username if you still have one, since it removes half the guessing work.
Enforce logout of stale sessions and change security salts if you suspect any compromise, which invalidates every existing session.
Layer three: file and server configuration
Configuration that limits what an attacker can do once they find a foothold.
Correct file permissions. Directories 755, files 644, wp-config.php at 600 or 640. Never 777 on anything, which is unfortunately common advice in old forum posts and is equivalent to leaving the file world-writable.
Disable the dashboard file editor. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php. This removes a convenient path from admin access to arbitrary code execution, and almost nobody edits theme files from the dashboard anyway.
Block PHP execution in uploads. A server-level rule preventing PHP from running in wp-content/uploads neutralises the most common location for an uploaded shell. This is one of the highest-value single rules available.
Move or protect wp-config.php. It holds database credentials and salts. Restrict access at the web server level.
Disable directory browsing so a misconfigured directory does not expose its contents.
Disable PHP execution in other writable directories where feasible.
Use SFTP or SSH, never plain FTP. FTP transmits credentials in clear text.
Keep separate hosting accounts or users per site if you run several. Cross-contamination between sites on one account is a real vector, and one compromised site should not reach the others.
Enforce HTTPS everywhere with proper redirects, and fix mixed content.
Set security headers at the server level: X-Content-Type-Options, X-Frame-Options or a frame-ancestors policy, Referrer-Policy, and HSTS once you are confident HTTPS works fully.
Layer four: monitoring and logging
The layer that determines whether a compromise lasts a day or six weeks.
File integrity monitoring. Alert on unexpected changes to core files, themes, plugins and anything in the web root. Most WordPress compromises modify files, and an alert on the day it happens converts a long silent compromise into a short contained one.
This is the single most valuable detection control available, and it is included in most security plugins.
Server-level malware scanning rather than plugin-only scanning, since an attacker with file access can disable a plugin.
Log retention of ninety days minimum, shipped off the server. Short retention is fine for debugging and useless for investigating a compromise that began earlier. If your site holds personal data, this is also a compliance capability, because India's breach reporting rules require a detailed account within 72 hours of awareness and that account is reconstructed from logs. The breach response playbook covers what that report must contain.
Alert on new administrator accounts. Attackers frequently create one for persistence, and this is a clean, low-noise signal.
Uptime monitoring from outside the server.
Watch Search Console for security notices, which is occasionally how site owners first learn they are compromised.
Review logs periodically. Not daily, but a monthly glance at failed login sources and unusual request patterns is useful.
| Control | Layer | Effort | Prevents or detects | Impact |
|---|---|---|---|---|
| Update plugins promptly | Updates | Low, ongoing | Most real compromises | Very high |
| Delete unused plugins | Updates | Low, one-off | Vulnerable dormant code | High |
| Two-factor on admins | Auth | Low | Credential attacks | Very high |
| Unique passwords | Auth | Low | Credential stuffing | High |
| Audit admin accounts | Auth | Low | Stale access | Medium to high |
| Block PHP in uploads | Config | Low | Uploaded shells | High |
| Disable dashboard file editor | Config | Very low | Admin to code execution | Medium to high |
| Correct file permissions | Config | Low | Unauthorised writes | Medium |
| File integrity monitoring | Monitoring | Low | Detects compromise early | Very high |
| 90-day off-server logs | Monitoring | Medium | Enables investigation | High |
| Offsite tested backups | Recovery | Medium | Enables clean recovery | Very high |
| Limit login attempts | Auth | Low | Brute force noise | Medium |
| Change login URL | Config | Low | Scanner noise only | Low |
Layer five: backups and recovery
Security is not only prevention. Assume something eventually gets through.
Three copies, one offsite at a different provider. A backup on the same server dies with the server, and is deletable by anyone who compromises it.
Retention long enough to predate a slow compromise. Seven days of backups is useless if the attacker has been present for five weeks, because every copy contains the backdoor. Tiered retention out to twelve months gives you a clean restore point.
Encrypt backups if the site holds customer data, and store the key separately.
Use restricted storage credentials so a compromised site cannot delete its own backup history. This is frequently overlooked and it is exactly what a competent attacker targets first.
Test a restore quarterly. An untested backup is a hypothesis. Restore into a throwaway environment and confirm the site comes up with data intact.
The 3-2-1 backup strategy covers the full pattern.
Security theatre worth skipping
Things widely recommended that deliver little, and occasionally cost something.
Changing the login URL. Reduces automated noise in your logs, which is mildly pleasant. It is not access control, since the endpoint is discoverable, and it breaks some integrations. Do it for tidiness, not protection.
Hiding the WordPress version number. Trivially determined from other signals, and it does nothing to stop a scanner that simply tries the exploit regardless.
Renaming the database prefix on an existing site. Meaningful benefit is limited, the operation is risky on a live site, and it addresses a narrow class of SQL injection that better practices already prevent.
Blocking all bots aggressively. Frequently blocks legitimate crawlers and monitoring, and attackers do not respect robots directives.
Running multiple security plugins. They conflict, duplicate scanning load, and degrade performance without adding protection.
Country-level IP blocking. Trivially bypassed with a proxy, and it blocks real customers and legitimate services. Rarely worth the collateral damage.
Obsessing over a security-plugin score. These scores weight configuration checkboxes, not real risk, and a site with a perfect score running an unpatched plugin is compromised anyway.
The general principle: measures that make an attack harder are worth doing; measures that make an attack marginally less convenient while breaking your own tools are not.
WooCommerce and sites holding customer data
Higher stakes, and a few additional considerations.
Use a hosted payment gateway. Redirecting to Razorpay, PayU, Cashfree or similar means card data never touches your server, which keeps you out of the heaviest PCI obligations. Handling cards directly on your own infrastructure is a substantially larger commitment.
Restrict who can view orders. Order data contains names, addresses and phone numbers. Shop Manager rather than Administrator for staff who need order access.
Limit data retention. WooCommerce accumulates customer and order data indefinitely by default. Define a retention policy, since indefinite retention of personal data conflicts with storage limitation expectations under India's data protection framework.
Guard the export function. A compromised admin account can export your entire customer database in one click.
Monitor for checkout tampering. Card skimmers injected into checkout are a specific and damaging attack, and file integrity monitoring on theme and checkout-related files is the practical detection.
Treat a compromise as a reportable breach. If an attacker had access to a system holding customer personal data, that is a personal data breach under DPDP regardless of whether you can prove exfiltration, with notification obligations and a 72-hour reporting clock.
FAQs
How do WordPress sites usually get hacked?
Overwhelmingly through vulnerable plugins and themes with published, already-patched flaws, found by automated scanners sweeping indiscriminately. Weak or reused credentials are the second most common cause. Targeted attacks against small business sites are rare; almost all compromises exploit known problems that the owner had time to fix.
Do I need a WordPress security plugin?
One is useful for file integrity monitoring, two-factor authentication and login rate limiting. Never run two, since they conflict and duplicate scanning load. A security plugin does not substitute for updating plugins promptly, which prevents more real compromises than any plugin configuration.
Is two-factor authentication necessary on WordPress?
Yes, on every administrator account. It is the single most effective control against credential-based attacks, because a password stolen from an unrelated breach becomes useless on its own. App-based TOTP is preferable to SMS. This is a few minutes of setup for a disproportionate reduction in risk.
Should I change my WordPress login URL?
It reduces automated scanning noise in your logs but is not access control, since the endpoint remains discoverable and it can break integrations. Do it if the log noise bothers you. Do not treat it as a security measure, and do not do it instead of enabling two-factor authentication.
What file permissions should WordPress use?
Directories 755, files 644, and wp-config.php at 600 or 640. Never 777 on anything. Also add DISALLOW_FILE_EDIT to wp-config.php to disable dashboard-based file editing, and block PHP execution in wp-content/uploads at the server level, which neutralises the most common location for an uploaded shell.
Is it enough to deactivate plugins I do not use?
No. Deactivated plugin files remain on disk and remain executable if reachable directly, and several notable WordPress vulnerabilities have been exploitable in plugins that were deactivated. Delete them. Every plugin you keep is code you are responsible for patching.
Are nulled or pirated premium plugins safe?
No. Nulled plugins are an established malware distribution channel, and the injected backdoor is frequently the entire purpose of the free distribution. You are installing attacker-controlled code with full access to your site and database. Buy the licence or use a free alternative.
How often should I update WordPress plugins?
Promptly, since the window between a vulnerability being published and exploited at scale is short. Enable automatic updates for plugins you trust and check weekly for the rest. If you are worried about updates breaking things, test on staging first rather than deferring the update.
Should I disable XML-RPC?
Usually yes, if nothing you use requires it. It is a frequent brute-force target because it permits many authentication attempts in a single request. Check first, since some mobile apps and remote publishing tools still depend on it, and disabling it while a tool needs it causes confusing failures.
How do I know if my WordPress site has been compromised?
File integrity monitoring is the most reliable early signal, alerting on unexpected changes to core, theme or plugin files. Also watch for administrator accounts you did not create, unfamiliar scheduled tasks, and pages in site:yourdomain.com results you never published. Much WordPress malware hides from logged-in administrators, so check as a search crawler would see the site.
Does hosting affect WordPress security?
Yes, meaningfully. Server-level malware scanning, log retention, isolation between accounts, current PHP versions and firewall rules all sit at the hosting layer. Poorly isolated shared hosting also allows cross-contamination between sites on the same account, which is a real vector when you run several sites.
What should I do first if I have done none of this?
Update every plugin, theme and core, then delete anything unused. Enable two-factor authentication on all administrator accounts and remove admins who no longer need access. Those two steps take an afternoon and address the large majority of realistic risk, which is more than any configuration tweak will achieve.
Conclusion
The layers are ordered deliberately, because effort spent on the outer ones returns far more than effort spent on the inner ones.
Update your plugins and delete the ones you do not use. Turn on two-factor for every admin and remove the admins who should not be there. Those two actions, done consistently, prevent most of what actually happens to WordPress sites, and neither is technically demanding.
Then the configuration layer: block PHP in uploads, disable the dashboard file editor, fix permissions. Cheap, one-off, meaningful.
Then detection, which is the layer that decides how bad a compromise gets. File integrity monitoring turns a six-week silent breach into a same-day alert, and ninety days of off-server logs is what makes investigation and, if personal data is involved, breach reporting possible at all.
Then recovery: offsite backups with retention long enough to predate a slow compromise, restricted storage credentials so the backups cannot be deleted from a compromised site, and a restore you have actually tested.
Skip the theatre. Hiding the login URL, obscuring the version number, and chasing a plugin's security score are not what stands between you and an automated scanner. The patch you have not applied is.
HostCloud includes server-level malware scanning, extended log retention, free SSL, account isolation and automated daily backups restorable from the panel, on Indian infrastructure. Plans start at ₹99 a month at https://hostcloud.in.