Advanced WordPress hardening

Introduction: hardening is not adding, it is removing

Hardening is almost always presented as a list of things to install. It is the opposite. Hardening a system means reducing what it can do, and most of the measures on this page require no additional software at all.

The single principle they all follow from:

you do not protect yourself against an unknown flaw, you reduce what that flaw can reach.

This article assumes the basics are done — strong passwords, two-factor authentication, up-to-date software, tested backups. If that is not the case, start with the 10-minute security audit.

1. Execution — the measure that neutralises the largest family of attacks

Forbid PHP execution in the uploads directory. A single server configuration rule, and it neutralises an entire class of vulnerabilities: the ones where an attacker manages to drop a file and then call it.

It is the best effort-to-effect measure on this whole list, and it is still missing from most installations because it is not visible from the WordPress dashboard.

Forbid file editing from the admin area (DISALLOW_FILE_EDIT). A compromised administrator account can then no longer write code from the browser. It does not prevent the intrusion: it prevents the intrusion from becoming total control.

Disable plugin installation from the admin area on sites where deployment goes through another channel (DISALLOW_FILE_MODS). This is more restrictive and does not suit every workflow — but where it does, it closes the main route to persistence.

2. Permissions — precise, not permissive

The rule is not "as restrictive as possible", it is "write access only where it is needed".

• Configuration files do not need to be writable by the web server in normal operation.
• The uploads directory needs write access; the plugins directory does not, except during an update.
• One permission left too open on a single directory cancels out the rigour of all the others.

⚠ The common mistake: applying very restrictive permissions, then loosening them "temporarily" to unblock an update — and forgetting. Write down the date when you do it; that is the only way it ever gets tightened again.

3. Capabilities — the point almost nobody looks at

WordPress assigns capabilities by role, and most sites use the default roles without ever reviewing them.

Three questions that almost always turn something up:

1. How many administrator accounts are there? On most sites, more than necessary. Each one is a complete key.
2. Does an author need to be able to install plugins? No. Yet roles widen over time, plugin after plugin, and nobody narrows them back.
3. Are there still accounts belonging to people who have left? An inactive account with privileges is a door nobody is watching any more.

The fix is not technical, it is organisational: an account review every quarter, with the date written down.

4. The admin surface

• Limit login attempts. This does not stop a targeted attack, but it removes the background noise that floods the logs and hides what matters.
• Restrict admin access by IP address when the team is stable. It is the most effective measure in this section and the least compatible with mobile work — a trade-off to make deliberately.
• Reduce exposed information. Not as protection: as hygiene. Expect no real effect from it.
• Monitor file integrity. You cannot recognise an unknown attack; you can recognise perfectly well that a file has changed without your knowing. That is the principle explained in proactive protection against zero-day threats.

5. What does NOT protect you, despite appearances

• Hiding the WordPress version. An automated scanner tries the exploit; it does not read a number.
• Moving the login page. Useful against noise, worthless against a flaw in a plugin: the exploit does not go through the form.
• A security score in a dashboard. An indicator that never goes down measures nothing.
• Stacking up security plugins. Two firewalls do not protect twice as much; they add two surfaces and a likely conflict.

6. The protocol, on one page

• PHP execution forbidden in the uploads directory — start here
• DISALLOW_FILE_EDIT active
• Permissions reviewed: write access only where needed, with a date on every exception
• Administrator accounts counted, and reduced to the number actually needed
• Inactive accounts deleted, not disabled
• Capabilities per role reviewed: who can install, who can publish?
• Login attempts limited
• Integrity monitoring active, with an alert that reaches a human the same day
• Restore genuinely tested, at least once, in a separate environment
• Plugin count reduced — see auditing your plugins in 5 steps

Conclusion

Advanced hardening is not about stacking defences: it is about reducing what a flaw can reach. The two highest-yield measures on this page — forbidding PHP execution in uploads and reducing the number of privileged accounts — cost no software and show up in no dashboard.

That is precisely why they are rarely applied: there is nothing to install, nothing to show, and no score that goes up.

The test that tells you where you stand: if an administrator account were compromised tonight, what could the attacker do that you cannot stop them doing today? The list of those actions is your work plan.

To continue: proactive protection against zero-day threats, the 10-minute security audit and auditing your plugins in 5 steps. Our premium plugins come with a full refund within 14 days: see the catalogue.