Security guide
How to secure a WordPress site: the Canadian business owner's guide
Most WordPress security advice is a list of plugins. This is the order of operations — what actually reduces risk, ranked by how much it reduces it, and what you can skip.
The uncomfortable truth about WordPress security
WordPress core is rarely the way in. Most compromises arrive through an outdated or abandoned plugin, a reused or weak password, or a hosting account that shares its weaknesses with its neighbours. Security that starts anywhere else is addressing symptoms. The order of operations below ranks the work by how much risk it removes.
That means most of what gets sold as "WordPress security" — a plugin that adds a firewall and a scanner — is addressing the symptom layer while the actual doors stay open. A firewall is worth having. It is not a substitute for updating the plugin it's protecting.
Rank your effort in this order:
- Update discipline (biggest risk reduction, lowest cost)
- Credential hygiene and 2FA
- Least-privilege user roles
- Hosting and PHP version
- Verified, off-site, tested backups
- Firewall and monitoring
- Hardening constants and file permissions
- Everything else
Anyone who sells you 6 before 1 is selling you a product, not security.
1 · Update discipline
Keeping plugins, themes and core current removes more risk than any product you can buy, because most exploited vulnerabilities already have a patch when they are used. Discipline means knowing what runs on the site, removing what is not needed, and updating on a schedule you set rather than in a panic.
Audit what you're running
Every plugin on your site is code you've delegated trust to. Ask three questions of each: When was it last updated? How many sites use it? Is there a maintained alternative? A plugin not updated in over a year on a site handling customer data is a decision, not an accident.
Delete, don't deactivate
A deactivated plugin still has its files on disk, and vulnerable code in a deactivated plugin is still reachable in some attack classes. If you're not using it, remove it.
Update on a schedule, not in a panic
Weekly is boring. Quarterly is a project. Batched updates are where breakage lives — see what happens when updates break a site.
2 · Credentials
Credential reuse is the second most common way in that we find. The fix is unglamorous: a unique generated password for every service, two-factor authentication on every administrator account without exception, named accounts instead of a shared admin login, and a rotation of application passwords and API keys whenever someone leaves.
- Unique passwords per service, generated, stored in a manager.
- Two-factor on every administrator. Not just yours.
- Remove the shared "admin" account. Named accounts only — you cannot audit what you cannot attribute.
- Rotate application passwords and API keys when anyone leaves.
3 · User roles
Every administrator account is an account that can install code, so most sites have too many of them. A writer needs the Editor role, a designer needs Editor plus theme access, and almost nobody else needs full administration. Review the list quarterly and ask who actually needs the access they hold.
Audit quarterly: Users → All Users, sort by role, and ask who actually needs it.
4 · Hosting and PHP
Your host is part of your security posture, not a neutral utility. A supported PHP version, isolation from other tenants, automatic off-site backups, a staging environment and a real security response process are the minimum. A cheap plan that provides none of them makes every other control weaker than it looks.
- Run a supported PHP version. Unsupported PHP receives no security patches, and a surprising share of WordPress sites run one.
- Prefer isolated environments over crowded shared hosting where a neighbour's compromise can become yours.
- Confirm your host actually provides: automatic off-site backups, a staging environment, and a real security response process.
5 · Backups that are actually backups
A backup you have never restored is a hypothesis. A real backup lives off the server, keeps versions going back further than the oldest plausible compromise, and has been restored to a staging site recently enough that you know the procedure works. Most sites have a copy on the same server and call it a backup.
- Off-site. A backup on the same server is not a backup — it's a copy that dies with the original.
- Versioned. If you only keep the last one and the compromise is three weeks old, you've backed up the compromise.
- Tested. Restore to a staging site once a quarter. This is the step everyone skips and the one that matters.
6 · Firewall and monitoring
Once the first five steps are done, a web application firewall earns its place: it buys time between a vulnerability disclosure and your update, and only pays off if the update follows. Monitoring is what tells you the time has run out: file integrity changes, new administrator accounts, failed logins, uptime and outbound mail volume.
Monitor: file integrity changes, new admin users, failed login patterns, uptime, and outbound mail volume. The last one catches spam compromises fastest and almost nobody watches it.
7 · Hardening
Hardening closes the doors that remain after updates, credentials, roles, hosting and backups are handled. The changes are small and permanent: disable the file editor, set correct file permissions, block PHP execution in the uploads folder, switch off XML-RPC unless something needs it, and force HTTPS with HSTS where you control it.
- Disable the file editor:
define('DISALLOW_FILE_EDIT', true);— stops an escalated account editing PHP from the browser. - Correct file permissions: directories
755, files644,wp-config.php440or400. - No executable PHP in
wp-content/uploads/. - Disable XML-RPC unless something you use needs it.
- Force HTTPS site-wide, HSTS where you control it.
8 · The Canadian layer nobody includes
Security guidance written for a US or Australian audience stops at the technical controls. If you operate in Canada, your obligations continue: PIPEDA requires safeguards proportionate to the information you hold and mandatory breach reporting, and Québec's Law 25 adds incident obligations, a privacy officer and administrative penalties. A security plan that ignores them is incomplete.
- PIPEDA requires safeguards proportionate to the sensitivity of the personal information you hold, and mandatory breach reporting to the Privacy Commissioner where there's a real risk of significant harm.
- Québec's Law 25 adds confidentiality-incident obligations, a designated privacy officer, and administrative monetary penalties.
- A form that collects customer data on a site with no verified backups and no incident process is a compliance issue, not only a technical one.
9 · AI-generated malware and automated attacks
Attackers now use language models to write and rewrite malware until signature scanners stop recognising it, and to turn a published plugin vulnerability into a working exploit within hours. The doors are the same three as before; what has changed is the speed, which makes update discipline and integrity monitoring the controls that still hold.
The tools have changed faster than the advice. The attack itself is automated end to end: a crawler finds the plugin version string, a script tries the exploit, a second script installs the payload and a third hides it. No human looks at your site until it is time to sell the access.
What this changes for a WordPress owner is the timing, not the doors. The three doors are the same — an outdated plugin, a weak credential, a careless host — but the window between a disclosure and an attempt is now measured in hours, and a scanner that relies on known signatures sees a payload it has never met.
What holds up:
- Update discipline with a short clock. Weekly batches are no longer conservative for plugins with a history of disclosures; those get patched the day the advisory lands.
- Integrity monitoring over signature scanning. A file that changed when nothing was deployed is the signal. It does not matter whether the scanner has a name for the payload.
- Behaviour, not reputation. Outbound mail volume, new administrator accounts, cron jobs that appeared overnight and PHP files inside
wp-content/uploads/are visible regardless of how the code was written. - Least privilege everywhere. An automated exploit inherits the rights of whatever it compromised. A plugin running as an editor-level integration does less damage than one holding an application password for an administrator.
- Verified backups older than the breach. Versioned, off-site, tested. If the only copy is last night’s, an attacker who has been inside for a week owns the backup too.
What does not help: a firewall rule set that updates monthly, a “security score” from a plugin that checks settings rather than files, and any product that promises protection from “AI attacks” as a category. The category is marketing. The behaviours above are the defence.
What we do
Everything above, applied, verified and monitored — plus the part you can't do from a checklist: watching for the disclosure that affects the specific plugin you're running, at 2am, before it's exploited.
Request a Security Analysis Book a Health Report