WordPress Hardening Checklist: What to Hand Your Developer

Most WordPress compromises do not come from a clever attack on WordPress itself. They come from an out-of-date plugin, a shared admin login, a backup nobody has restored, or a server setting nobody checked. That is good news, because those are checkable.

This is the checklist we would give a business to hand to its developer or agency. It follows the WordPress project’s own Hardening WordPress guidance and adds what we see on real sites. It also covers what hardening does not fix, because that is where many “secured” sites still get caught.

Why the plugin ecosystem is the main risk

Patchstack’s State of WordPress Security report (updated 25 February 2026) counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024. Of those, 91% were in plugins and 9% in themes. Only 6 were in WordPress core. It also reported that 46% of the year’s vulnerabilities had no fix from the developer in time for public disclosure.

Read that as a priority order. Core is rarely the problem. The plugins and themes you add, and whether anyone maintains them, are.

The checklist, grouped

1. Hosting and server

• Supported PHP and database. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. It notes that WordPress still runs on PHP 7.4+ and MySQL 5.5.5+, but says those versions are past their support lifecycle and “may expose your site to security vulnerabilities”.
• HTTPS everywhere, including the admin area. The handbook recommends requiring an encrypted connection for administration.
• SFTP, not FTP, where your host offers it.
• Separate sites, separate accounts. Run each site with its own database and database user. One compromised site should not give access to the others.
• Least database privilege. Normal operation needs SELECT, INSERT, UPDATE and DELETE. The handbook warns that removing DROP, ALTER or GRANT can break schema updates, so take a backup first and test.

2. Core, plugin and theme updates

WordPress applies minor core updates to existing installs by default. Major releases update automatically by default only on new installs from WordPress 5.6, and plugins and themes are not updated automatically except in special cases decided by WordPress.org for critical vulnerabilities. So the rest is a process someone must own.

• Name the person or agency responsible for updates, and how often they run.
• Update on staging first for anything with custom code or WooCommerce, then production.
• Delete plugins and themes you are not using. Deactivated is not removed.

3. Accounts and access

• Two-factor authentication for every administrator and editor. The handbook calls it a good idea as an additional security measure.
• Single sign-on where you have an identity provider. On a hospitality client’s WordPress site we are adding SAML single sign-on through the client’s own Microsoft Entra. Sign-in and leaver removal then sit with the client’s identity provider.
• Named accounts only. No shared “admin” login, and avoid usernames like admin.
• Least privilege. Editors should not be administrators. Review the user list quarterly and remove ex-staff and ex-contractors.
• Strong, unique passwords in a password manager.

4. File permissions and wp-config

• Directories at 755 and files at 644, per the handbook.
• wp-config.php at 400 or 440, and optionally moved one directory above the web root, though the handbook notes the benefit is small.
• Add define( 'DISALLOW_FILE_EDIT', true ); to switch off the dashboard file editor. The handbook is candid that this “will not prevent an attacker from uploading malicious files”, but it may stop some attacks.
• Change the database table prefix from wp_. The handbook says this can block at least some SQL injection attacks, though it is a small gain.
• Rotate the authentication salts after any suspected compromise or staff change.

5. WAF and CDN

A web application firewall (WAF) filters malicious traffic before it reaches WordPress. Cloudflare is a common choice, and our Cloudflare partner page covers how we set it up. Two things worth knowing, both covered in more depth in our post on Cloudflare WAF for Magento and equally true for WordPress.

• Managed rules arrive after someone has analysed an attack, so a WAF protects against yesterday’s exploits more reliably than a zero-day on the day it lands.
• Rate limiting and bot rules on wp-login.php and xmlrpc.php matter. If you do not use XML-RPC, block it.

Keep the origin server reachable only through the CDN or WAF where you can, or the protection can be bypassed.

6. Backups and restore tests

The handbook asks for regular backups of the files and the database, stored somewhere trusted. Australia’s cyber agency lists regular backups as one of the Essential Eight mitigation strategies, alongside patching applications, multi-factor authentication and restricting administrative privileges. Those four map straight onto sections 2, 3 and 6 of this checklist.

• Keep copies off the server, with a copy that your WordPress admin account cannot delete.
• Restore a backup to a staging site at least twice a year. A backup you have never restored is a hope, not a control.
• Write down who can trigger a restore and how long you expect it to take.

7. Monitoring and logging

• Uptime monitoring and an alert when the site returns errors.
• Server access and error logs retained long enough to investigate an incident.
• File-integrity monitoring or version control, so an unexpected change to core or plugin files shows up. The handbook names OSSEC and Git as examples.
• Alerts for new administrator accounts and for failed-login spikes.

8. Plugin vetting and abandonment

• Install only from trusted sources: the WordPress.org repository or established vendors.
• Before adding a plugin, check the last update date, active installs, support responses and whether it has a history of disclosed vulnerabilities.
• Keep a plugin register with each plugin’s purpose, owner and last-updated date, and review it every quarter.
• When a plugin is abandoned, plan a replacement, not a workaround. On a current hardening engagement we are starting with a plugin audit, then replacing plugins with client-owned alternatives (SSO and a mail sender), and closing each finding only with verification evidence.

The checklist as a table

Control	Why	How to check
Supported PHP and database versions	End-of-life versions get no security fixes	Site Health in the dashboard, or the host control panel
HTTPS and HTTPS-only admin	Stops credentials crossing the network in plain text	Browse to http:// and confirm it redirects
Update owner and schedule	Plugins do not auto-update by default	Ask who runs updates and read the last change record
Unused plugins and themes removed	Every installed plugin is attack surface	Plugins screen shows nothing you cannot justify
2FA or SSO for all privileged users	Stolen passwords stop being enough	Log in as each role type from a fresh browser
Least-privilege users	Limits damage from one compromised account	Users screen, reviewed quarterly
File permissions 755 / 644, wp-config.php 400 or 440	Stops web processes rewriting code	SSH ls -l, or the host file manager
DISALLOW_FILE_EDIT	Removes the in-dashboard code editor	Appearance menu has no Theme File Editor
WAF with login rate limiting	Blocks known exploits and brute force	Hit wp-login.php repeatedly from a test IP and confirm a challenge
Origin locked to the CDN	Stops attackers bypassing the WAF	Request the origin IP directly and confirm it is refused
Off-server backups	Survives a server compromise	Locate the copy and confirm the admin account cannot delete it
Restore test	Proves the backup works	Restore to staging and load the site
Logging and alerts	Shortens time to notice an incident	Trigger a test event and see whether anyone is told
Plugin register	Surfaces abandoned plugins early	Open it: does every row have an owner and a date?

What hardening does not fix

Hardening shrinks the attack surface. It does not repair code that is already vulnerable.

• Abandoned plugins. If a plugin has a known flaw and no maintainer, a firewall rule is a patch over a patch. The fix is replacement or removal.
• Flaws in custom code. A custom plugin, theme or integration can contain injection, access-control or file-upload bugs that no setting will catch. They need someone to read the code.
• Compromised credentials already in use. Rotating salts and passwords helps, but you also need to find how the attacker got in.
• Third-party services. Payment gateways, form tools and SSO providers have their own security posture.

When to ask for a code audit

A configuration review checks settings, access and backups. A code audit is a different job: reading the plugins and theme for vulnerabilities, with a written list of findings ranked by risk. Ask for one when:

• The site has custom plugins, a bespoke theme or integrations built by someone no longer around.
• You handle payments, membership data or other personal information.
• A plugin you depend on is abandoned and cannot be replaced quickly.
• The site has been compromised before, or you are inheriting it from another agency.
• A customer or auditor has asked for evidence of security testing.

Our WordPress development team works on WordPress hardening, plugin replacement and ongoing support. If you are weighing WordPress against something else for a security-sensitive site, our post on whether WordPress is enterprise-ready covers where it holds up and where it does not.

A simple order of work

1. Confirm who owns hosting, DNS and every admin account.
2. Take a backup and restore it to staging.
3. Update PHP, core, plugins and themes, and remove what you do not use.
4. Turn on 2FA or SSO and clean up users.
5. Set permissions and wp-config.php, then put a WAF in front.
6. Add monitoring and write the plugin register.
7. Book the first quarterly review before you finish.

Sources: Hardening WordPress, developer.wordpress.org; WordPress requirements, wordpress.org; Upgrading WordPress, developer.wordpress.org; State of WordPress Security in 2026, Patchstack; Essential Eight explained, cyber.gov.au. All checked November 2026.