Priority 1: establish a trusted baseline
- update WordPress, plugins, themes, PHP, and server components
- remove unused code and accounts
- verify core and extensions against trusted sources
- limit administrator privileges
- rotate passwords, sessions, salts, API credentials, and application passwords
Priority 2: restrict execution and access
Block PHP execution in uploads, cache, and data directories where the application does not require it. Apply least-privilege file permissions, disable dashboard file editing, use encrypted administration channels, and protect privileged identities with multi-factor authentication.
Hosting-specific controls
Apache, Nginx, CDN, and managed-hosting controls differ. Apply platform-specific rules and functionally test them.
Priority 3: recovery and detection
- separate automated backups with restore tests
- an integrity baseline for controlled code
- central logs with suitable retention and access controls
- alerts for administrators, file changes, and WAF events
- a documented incident contact and escalation path
A green scanner result is not an ongoing security guarantee. Controls need regular verification.
What must be established before hardening?
Hardening does not resolve an unexplained incident. If unknown administrators, modified code, or active redirects remain, the environment first needs controlled remediation. Otherwise, new restrictions can hide symptoms while persistence survives.
Inventory the hosting model, web server, PHP version, deployment path, caches, CDN/WAF, outbound email, schedulers, and external integrations. A rule designed for one Apache configuration may be ineffective—or disruptive—on Nginx or managed hosting.
How should the attack surface be reduced?
Every component, identity, and interface needs a current business purpose. Remove disabled plugins and themes rather than leaving their code installed. Review and then remove former administrators. Restrict XML-RPC, REST endpoints, and remote administration only after establishing which legitimate workflows depend on them.
Updates are necessary but not a standalone control. Verify recoverability and compatibility, update from trusted sources, and test critical user journeys. A component that is no longer maintained has no sustainable patch path and should be replaced.
Which identity controls are essential?
Administrative identities need unique passwords, multi-factor authentication, and the minimum role required. Shared accounts weaken accountability. Name service accounts and application passwords by purpose, scope them narrowly where possible, and review them on a schedule.
Treat WordPress, hosting, DNS, CDN, and email as separate trust boundaries. A compromised mailbox may enable password resets; a compromised DNS account can redirect visitors while the WordPress files remain untouched. Store recovery codes outside the website in protected storage.
How should file writes and execution be restricted?
The web-server process should write only where the application requires it. Ideally, core, plugin, and theme code changes arrive through a controlled deployment or update path. Block script execution in uploads and cache directories where the platform does not require executable code.
Avoid universal numeric file-permission recipes. Ownership, groups, PHP execution, and deployment models differ. The objective is that an unprivileged process cannot overwrite administrative code and that secrets are not readable from public paths.
Test enforcement and functionality
A security rule is complete only after verification. Test both the blocked behaviour and legitimate uploads, forms, checkout, cron, REST integrations, and deployment.
Which transport and browser controls help?
TLS protects data in transit. HSTS can prevent protocol downgrade but should follow complete HTTPS coverage. Content Security Policy reduces classes of browser-side attack when its directives reflect the real site. X-Content-Type-Options, a deliberate referrer policy, and frame restrictions add further browser boundaries.
Headers do not replace server-side validation or malware removal. A permissive CSP full of wildcards can look stronger than it is, while a rushed policy can break payment, consent, and form integrations.
What makes backups resilient?
Keep backups separate from the production account, transfer them securely, restrict access, and retain multiple recovery points. A backup stored in a web-accessible or writable site directory may be altered or stolen with the live environment.
Test restoration, not merely creation. Can a defined version be recovered in an isolated environment? Are database, media, configuration, and necessary secrets accounted for? The guide to compromised historical backups explains why age alone does not establish trust.
What detection is realistic?
Monitor new privileged users, authentication failures, controlled-file changes, WAF events, unexpected schedulers, and meaningful outbound-traffic deviations. Every alert needs an owner and response path; an unattended notification is not an operational control.
Store logs where an attacker with website access cannot simply erase them. Choose retention based on operational, security, and privacy requirements. The incident-log guide prioritizes evidence to preserve.
What does a documented acceptance test contain?
For every control, record the intended state, actual configuration, test, result, owner, residual risk, and next review date. Open items receive a priority and justified deadline. This makes later review possible and prevents “hardened” from meaning only a one-time impression.
The methodology connects acceptance testing with finding classes and explicit limitations. Server and firewall hardening covers layers outside WordPress itself.