Treat WordPress as a maintained application
WordPress security is an operating practice, not a one-time plugin installation. Maintain an inventory of core, themes, plugins, custom code, hosting services, DNS, email delivery, analytics, and administrators. Assign an owner and update path to each part. Remove inactive themes and plugins rather than leaving unused code installed.
Install WordPress, themes, and plugins only from trusted sources. Review support history, update frequency, install base, ownership changes, and required permissions before adding an extension. Test updates in a representative environment, back up first, and apply security fixes promptly. The official Hardening WordPress guide emphasizes updates, trusted sources, containment, backups, logging, and monitoring.
Protect administrator and supplier access
Require unique accounts, strong passwords, and multi-factor authentication for administrators. Do not share a generic administrator login. Give editors, marketers, developers, and integrations only the capabilities they require, and review accounts when staff or vendors change.
Rate-limit login and password-recovery attempts. Protect hosting, registrar, CDN, source-control, and backup accounts with the same care as WordPress itself; control of any one of them may allow a site takeover. Use encrypted administration connections and SFTP or managed deployment instead of plain FTP.
Disable the built-in theme and plugin file editor in production where it is not required. Restrict XML-RPC, application passwords, REST endpoints, and remote publishing features according to actual business use rather than disabling them blindly.
Harden files, database, and hosting
Run supported PHP, database, web-server, and operating-system versions. Use a separate database identity with only needed privileges and distinct credentials per site. Keep configuration and backups out of the public web root where the hosting architecture permits it.
Set file ownership and permissions so the web process cannot modify application code broadly. Only upload, cache, and explicitly required directories should be writable. Prevent PHP execution in upload directories and protect sensitive files such as configuration, logs, and exports.
Use HTTPS everywhere and configure security headers at the CDN or origin. A web application firewall can reduce exposure to common and automated attacks, but it does not repair vulnerable plugins or replace secure development. Origin access should be restricted where traffic is expected to pass through an edge service.
Secure forms, content, ecommerce, and integrations
Keep form and ecommerce plugins current and collect only the information the business needs. Protect submissions against CSRF, spam, and automated abuse; restrict file uploads; and set retention and deletion rules. Payment data should remain within approved payment-provider flows rather than being stored by general-purpose WordPress forms.
Review marketing pixels, chat widgets, tag-manager containers, embeds, and API keys. Document what data each service receives and ensure consent behaviour matches the privacy notice. Validate webhook signatures and give integration tokens narrow permissions.
Custom themes and plugins should use WordPress escaping, sanitization, nonces, capability checks, and parameterized database APIs. A nonce helps with request intent but does not replace authorization.
Monitor and prepare to recover
Send useful logs to a location an attacker cannot easily alter. Monitor administrator creation, plugin and theme changes, failed logins, file changes, unexpected redirects, outbound spam, and integrity warnings. Establish who investigates an alert and how quickly.
Maintain versioned, encrypted backups of both files and the database in a separate account or service. Test restoration rather than assuming a successful backup job means recovery will work. An incident plan should cover containment, evidence preservation, credential rotation, clean rebuilding, notification assessment, and post-recovery monitoring.
WordPress security review checklist
- Core, plugins, themes, PHP, and hosting components are supported and current.
- Every extension has a business owner; unused code is removed.
- Administrator, hosting, DNS, CDN, and backup access use MFA and least privilege.
- Files, database credentials, uploads, configuration, and origin access are hardened.
- Forms, custom code, ecommerce, and third-party scripts are reviewed as data flows.
- Logs and file monitoring have alert owners and response procedures.
- Complete restoration from an independent backup has been tested.
