WordPress security checklist 2026

The 2026 checklist

Use this as the high-level pass. The sections below explain why each item matters and what to check first.

1. Update WordPress core, plugins, and themes; remove anything abandoned.
2. Inventory plugins by purpose, owner, and vulnerability exposure.
3. Reduce Administrators and apply least privilege to every user.
4. Require 2FA for privileged accounts and rotate stale application passwords.
5. Harden wp-login.php with lockouts, rate limits, and conditional CAPTCHA.
6. Disable or rate-limit xmlrpc.php.
7. Review wp-config.php: salts, debug flags, SSL admin, file edit constants, database credentials.
8. Set sane file permissions and block PHP execution in uploads.
9. Enforce HTTPS, secure cookies, and essential security headers.
10. Verify backups by restoring them, not just by seeing a green check mark.
11. Scan for malware, web shells, suspicious admin users, and modified core files.
12. Log important events and review alerts after admin activity spikes.

Core, plugin, and theme updates

Most mass WordPress compromises target known vulnerabilities in plugins and themes, not brand-new zero-days. Your first job is to remove the known attack paths before scanners find them.

• Core: keep minor/security releases automatic. Test major releases in staging before production.
• Plugins: update actively maintained plugins, then remove disabled plugins you are not using.
• Themes: keep the active theme and parent theme updated. Delete old themes except one default fallback if your workflow needs it.
• Abandoned code: replace plugins with no recent maintenance, unresolved security reports, or incompatibility with current PHP/WordPress versions.

Do not let "disabled" create false comfort. A disabled plugin can still leave files on disk, and direct file access vulnerabilities do not always care whether the plugin is active.

Plugin risk and unused code

Plugin count alone is a weak metric. Ten well-maintained plugins can be safer than three abandoned ones. Review plugin risk by capability and exposure:

1. Does it handle uploads, forms, payments, membership, login, redirects, or email?
2. Does it create public endpoints, REST routes, AJAX actions, or shortcodes?
3. Does it store secrets, API keys, personal data, or order data?
4. Does it require broad admin capabilities like manage_options?
5. Is there a clear owner who will update and test it?

High-exposure plugins are not automatically bad. They just deserve more attention. Contact forms, ecommerce, LMS, booking, and membership plugins sit directly on the boundary between visitors and your database.

Users, roles, 2FA, and passwords

Access control is where many clean-looking WordPress sites are weakest. Use the official WordPress roles model as your baseline, then tighten from there.

• Remove users who no longer need access.
• Downgrade Administrators who only need content, SEO, support, or store-management access.
• Require 2FA for Administrators, developers, shop managers, editors, and customer-data roles.
• Use unique passwords from a password manager.
• Review application passwords and API tokens quarterly.
• Set display names that do not reveal admin usernames.

OWASP recommends multi-factor authentication as a core authentication control. In WordPress, that starts with high-privilege accounts and expands to any account tied to money, private content, or customer data.

Login page, lockouts, and XML-RPC

Login hardening is about making automated guessing expensive. A reasonable 2026 baseline:

• Change the public login URL if it reduces bot noise for your site.
• Apply a lockout rule around 5 failed attempts in 15 minutes, with temporary lockouts and exponential backoff.
• Use CAPTCHA after failures, not necessarily on every clean login.
• Return generic login errors that do not reveal whether a username exists.
• Disable or rate-limit xmlrpc.php.
• Alert on repeated failures against Administrator accounts.

The login page is only one credential endpoint. XML-RPC, REST API integrations, application passwords, and stale sessions all need review too.

wp-config.php and secrets

wp-config.php contains database credentials, salts, and security-sensitive constants. Treat it as a secret file, not a normal config sample.

1. Replace placeholder salts and rotate old salts after staff changes or suspected compromise.
2. Use a dedicated database user, not root.
3. Set DISALLOW_FILE_EDIT to true so a compromised admin cannot edit PHP from the dashboard.
4. Use FORCE_SSL_ADMIN on HTTPS sites.
5. Turn off WP_DEBUG_DISPLAY in production.
6. Set file permissions around 640 where your host supports it.

Secrets should not be committed to a repository, emailed to vendors, or left in old backup zips under the web root.

File permissions and upload safety

WordPress needs to write some files, but the web server should not have broad write access everywhere. A practical baseline is directories at 755, files at 644, and wp-config.php tighter where possible. Avoid 777; it is a workaround that turns a small bug into a larger compromise.

Uploads deserve special treatment. Attackers love upload folders because they are writable and public. Block PHP execution in wp-content/uploads with web-server rules, validate MIME types, and review any plugin that accepts public uploads.

HTTPS, headers, and cookies

HTTPS is table stakes, but the details still matter:

• Redirect HTTP to HTTPS site-wide.
• Set HSTS when you are confident HTTPS is stable.
• Use secure cookies for authenticated sessions.
• Add X-Content-Type-Options: nosniff.
• Use a reasonable Content-Security-Policy where the theme and plugins allow it.
• Set clickjacking protection with frame-ancestors or X-Frame-Options.

Headers will not patch a vulnerable plugin, but they reduce the blast radius of browser-side bugs and misconfigurations.

Backups, logging, and recovery

Backups are a security control only if you can restore them. A backup plugin reporting "success" is not enough.

1. Store backups off-server so ransomware or hosting compromise cannot erase them.
2. Keep multiple restore points, not just the latest copy.
3. Test a restore into staging at least quarterly.
4. Protect backup archives from public download.
5. Log user creation, plugin installation, theme edits, option changes, and file changes.

Recovery speed matters. During a real incident, you need to know which backup is clean, who has access to restore it, and how long the site can be down.

Map the checklist to Lockora

Lockora is built to turn this checklist into a repeatable scan. It checks WordPress version drift, plugin and theme risk, exposed login endpoints, XML-RPC, user roles, stale admin accounts, weak usernames, 2FA coverage signals, wp-config.php constants, file permissions, debug leakage, suspicious files, modified core files, and unsafe upload behavior.

The output is grouped by fix, not just by finding. That means a site owner can see "reduce admin risk" as one workstream and "harden exposed authentication endpoints" as another, instead of sorting through disconnected warnings.

Common questions

How often should I run a WordPress security checklist?

Run a quick version monthly, after every major plugin or theme change, and before large marketing campaigns. Run the full checklist quarterly or after any suspected compromise.

Do I need a security plugin and a checklist?

Yes. A plugin can scan and enforce controls, but the checklist forces ownership decisions: who needs admin access, which plugins still matter, whether backups restore, and what risk the business accepts.

What is the highest-priority item?

For most sites: update vulnerable plugins, reduce Administrator accounts, require 2FA, and protect login/XML-RPC endpoints. Those four items remove a large share of common compromise paths.