CMSSecurityBestPractices

We get called in after a security incident more often than we'd like. Most of these breaches trace back to a small set of avoidable gaps, regardless of whether the site runs WordPress, Drupal, or a headless setup. Here's what we check first, and what we configure by default on every CMS build we hand off.

Patch cadence is the single biggest factor

The WordPress and Drupal security teams both publish advisories on a predictable schedule, and the vast majority of real-world compromises we investigate exploit vulnerabilities that were patched publicly weeks or months earlier. If your site is running WordPress core more than two minor versions behind, or a Drupal core version that's past its supported window, you are carrying known, documented risk. We set every managed client up with automatic minor-version updates and a monthly manual review for major version changes that might break plugins or modules.

Plugin and module sprawl

Every additional plugin is additional attack surface. We routinely find client sites running 40–60 plugins, many installed once for a single campaign years ago and never removed. Our standard audit process: export the full plugin/module list, cross-reference each one against its last update date and open vulnerability reports on WPScan or the Drupal security advisory database, then flag anything unmaintained for removal or replacement. A site running 15 well-maintained plugins is safer than one running 50, even if some of those 50 are individually secure.

Login hardening

Default WordPress and Drupal login pages at /wp-admin or /user/login are the first thing automated bots probe. Our baseline configuration on every build:

• Rate limiting on login attempts (5 attempts, then a 15-minute lockout)
• Two-factor authentication required for all admin and editor accounts
• Renaming or restricting access to the default login URL where the platform supports it
• Disabling XML-RPC on WordPress sites that don't need it for a specific integration

File permissions and the uploads directory

A surprising number of compromises we investigate involve a malicious PHP file uploaded through a form or media library and then executed directly. The fix is server-level: the uploads or files directory should have PHP execution disabled entirely, so even if a bad file lands there, the server won't run it. We verify this with a direct test — attempting to execute a harmless test script from the uploads path — as part of every security audit.

Database credentials and secrets

Database credentials, API keys, and SMTP passwords should never sit in a config file that's readable outside the application layer, and they should never be committed to a public repository. We've found live database credentials in public GitHub repos for client sites more than once during onboarding audits. Rotating credentials and moving secrets to environment variables is a one-afternoon fix that closes a serious hole.

Backups you've actually tested

A backup you haven't restored from is a backup you don't actually have. We require automated daily backups stored off-server (not in the same hosting account, ideally in a separate Canadian data centre or cloud region for PIPEDA-conscious clients), plus a quarterly test restore to a staging environment to confirm the backup file actually works. We've seen clients discover their "backups" had been silently failing for eight months only after a ransomware incident.

SSL, headers, and a basic WAF

TLS 1.2 minimum (1.3 where your hosting supports it), HSTS enabled, and security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options) configured at the server level catch a meaningful share of drive-by attacks before they reach the application. A web application firewall — Cloudflare, Sucuri, or a managed host's built-in WAF — adds another layer that blocks known attack signatures before they hit your CMS at all.

None of this is exotic. It's a checklist, and most of it takes a day or two to implement properly on an existing site. If you're not sure which of these your current site has, we offer a fixed-fee security audit that walks through each item above and hands you a prioritized fix list.