We build some client sites on WordPress, including our own. It's a good choice for content-heavy sites that non-developers need to edit. It's also the platform bots scan most, so every WordPress site we launch goes through the same hardening pass. The time needed depends on the site and its plugins.
Accounts and logins
- No user called
admin. Bots try it first. Each person gets their own account with the lowest role that lets them do their job. Editors don't need to be administrators. - Two-factor or passkeys for every administrator. A plugin handles this in minutes.
- Rate-limit the login page. Your host or a security plugin can block an IP after a few failed attempts. This stops most credential-stuffing noise.
- Disable XML-RPC unless you use the mobile app or a service that needs it. It's an old API that attackers use to try many passwords in one request.
Files and code
- Turn off the built-in file editor. Add
define( 'DISALLOW_FILE_EDIT', true );towp-config.php. If someone gets into an admin account, they can't paste code into your theme from the dashboard. - Correct file permissions. Directories at 755, files at 644,
wp-config.phptighter. The web server shouldn't be able to write to theme and plugin folders in production. - Move secrets out of the repo. Database passwords and salts belong in environment settings or a
wp-config.phpthat stays off git.
Plugins and themes
Most WordPress breaches start with a plugin. Our rules:
- Install only what the site uses. We delete inactive plugins and themes instead of leaving them switched off, because inactive code can still be reached and still has bugs.
- Prefer plugins with recent updates and many active installs. A plugin that hasn't been updated in two years is a liability.
- Turn on automatic updates for minor releases and security fixes, and test major updates on a staging copy first.
Server and headers
- HTTPS everywhere, with HTTP redirected.
- Security headers:
Strict-Transport-Security,X-Content-Type-Options,Referrer-Policyand a basic Content Security Policy. - PHP errors logged to a file, never shown on the page.
- Directory listing off, so nobody can browse
/wp-content/uploads/like a file manager.
Backups you have tested
We set daily backups of files and database, stored away from the server, and we restore one to a staging site before launch. A backup you've never restored is a guess.
After launch
Hardening decays. Someone installs a plugin for a quick fix, a new staff member gets an administrator account "temporarily". We review users and plugins every quarter and keep a changelog of what we changed and why. If you'd like the same review run on your site, the checklist above is where we start.
