WordPress Hardening

WordPress hardening.

Closing the attack surface before the attack arrives. The editorial position is that most WordPress compromises are preventable at the configuration layer, and that hardening work is cheaper, faster, and more durable than cleanup. This is where that work lives.

What this desk covers.

Six beats. Each is a distinct hardening surface. We cover them as procedures we have actually run on live installs, not as lists we found on someone else’s blog.

01

Authentication

Strong passwords, two-factor authentication, login URL controls, brute-force lockouts, session hijack detection. The single largest intrusion vector in our incident data.

02

File and permission hygiene

WordPress file and directory permissions, ownership under the web user, read-only wp-config.php where possible, permissions drift detection. Mundane and high-impact.

03

HTTP attack surface

XML-RPC, REST API permission callbacks, pingback controls, file-edit disable, directory indexing. The WordPress endpoints attackers hit first.

04

Security headers

HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy. The hardening layer most WordPress sites never configure and Google silently penalizes.

05

Updates and patch policy

Core, plugin, and theme update cadence. Auto-update policy. Release-candidate testing. The operational discipline that keeps known-vulnerable code off production.

06

Backups and recovery

What to back up, where, how often, and how to restore under pressure. The hardening layer you only appreciate at 3am on the day of a compromise.

Pieces from this desk.

When hardening is not enough.

Hardening reduces incident probability. It does not eliminate it. The pieces below are what runs when a compromise happens anyway, and the tools we evaluate for automating the hardening layer on sites with more than a handful to manage.

Scroll to Top