WordPress Security Hardening
Scan findings verified live, then closed with defense in depth
Context
WordPress sites needed defense in depth rather than a single security plugin left on defaults. On the anchor engagement, the starting point was an external scan scoring the production site 79/100 with a list of reported issues, and scan output is where the real work begins, not ends: findings had to be reproduced against production before anything changed, because hardening against false positives is wasted motion and hardening that breaks integrations is worse than the exposure.
Every reported finding was verified live, 7 confirmed, zero taken on faith, then closed in severity order with a dependency check ahead of each fix. The work spanned an application-layer firewall, vulnerability-database virtual patching, HTTP security headers, and surface-reduction measures closing the standard WordPress attack vectors, finishing with an auditable record of what was locked down and why.
The Challenge
- The critical finding, exposed XML-RPC, is also the one that breaks things when blocked blindly: legacy integrations and remote-publish tooling depend on it, so dependencies had to be audited first.
- Scanner output mixes real exposure with noise; treating the report as a to-do list without live verification produces hardening theater.
- A Content-Security-Policy on a production site is a breaking change waiting to happen, it needed a staged rollout, not a heroic one-liner.
- The site runs live automations; any hardening that disturbed their API access would have turned a security win into an operations incident.
Scope and Approach
-
01
Finding verification
Reproduced every scan finding directly against production, request by request, confirming 7 as live exposure and discarding the rest. Hardening addressed demonstrated risk, not a generic checklist.
-
02
WAF and virtual patching
Deployed Wordfence as the application-layer firewall and Patchstack for vulnerability-database virtual patching, known CVEs in plugins and core mitigated at the edge during the window between disclosure and update.
-
03
Dependency-checked surface reduction
Closed the confirmed vectors in severity order: XML-RPC blocked only after auditing that every integration ran on the REST API and nothing depended on it, killing the brute-force amplification and pingback-reflection surface with zero collateral damage.
-
04
Disclosure and header hardening
Disabled directory indexing on the uploads tree, denied the default readme and license files, stripped the WordPress version from generator meta and RSS, and restored Referrer-Policy at the server layer, each an information leak that feeds automated target selection.
-
05
Staged CSP rollout
Shipped a baseline Content-Security-Policy immediately and scoped the full script/style policy as its own test cycle, because a rushed CSP breaks production quietly, in exactly the browsers nobody tested.
-
06
Verification and record
Re-verified each control after deployment, the same requests that proved the exposure now proving the closure, and documented what was locked down and why. Auditable hardening, not opaque protection.
Architecture flow
Technical Deep Dive
Why XML-RPC was the critical finding
Exposed XML-RPC offers system.multicall credential brute-forcing, hundreds of password attempts per HTTP request, invisible to naive rate limiting, and the pingback method doubles as a DDoS reflection primitive against third parties. Blocking it is trivial; blocking it safely required proving the site's automations used REST exclusively. That dependency audit is the difference between hardening and gambling.
Virtual patching as a time-window strategy
Plugin CVEs are exploited within days of disclosure; site update cycles are slower. The vulnerability-database layer mitigates known signatures at the firewall while updates catch up, covering the gap where most real-world WordPress compromises happen.
CSP in phases
The baseline policy delivers immediate protection headroom; the full script/style allowlist requires inventorying every legitimate inline script, third-party embed and style injection on the site, work that belongs in its own test cycle with report-only observation before enforcement.
Version disclosure feeds target selection
Mass WordPress exploitation is version-indexed: crawlers harvest generator tags, RSS versions and default files to build target lists for the next disclosed CVE. Stripping the version and denying the default files does not fix a vulnerability, it removes the site from the cheap-target inventory, which is what most opportunistic compromise actually keys on.
Engineering Decisions
Verify before hardening
Reproducing findings first cost hours and saved the engagement: it separated the 7 real exposures from scanner noise, correctly ranked severity, and meant every fix could be re-verified with the same request that proved the problem.
Layers over a single "security plugin"
Firewall, virtual patching, headers and surface reduction each cover failures the others miss. One plugin on defaults is a checkbox; independent layers are a posture.
Server-layer fixes where possible
The surface-reduction controls live in server configuration and small versioned snippets rather than inside another plugin, they survive plugin updates, theme changes and admin turnover, and each one is individually reviewable and reversible.
Results
- 7 live-confirmed findings, 7 corrected, including a critical XML-RPC exposure open to brute-force amplification and pingback DDoS reflection.
- Every fix dependency-checked against the stack first, hardening that never broke the automations the business runs on.
- Defense in depth across WAF, virtual patching, headers and attack surface, not a single plugin on defaults.
- Baseline CSP live, full policy scoped as a safe, staged rollout.
- An auditable record of what was locked down and why.
Have a system that needs
this kind of work?
Tell me what is breaking or what you need built. I will reply with how I would approach it and what I would check first.