Drupal has one of the strongest security track records of any major CMS — but that reputation only holds if the site is actually maintained. An unpatched Drupal 9 instance is not more secure than an unpatched WordPress instance. Here’s what actually keeps a Drupal site safe.
What’s the Most Common Way Drupal Sites Get Compromised?
Almost never through a flaw in Drupal core itself. It’s nearly always one of these:
- An outdated contributed module with a known, published vulnerability that was never patched
- Weak admin credentials without two-factor authentication
- An abandoned module left installed and enabled long after it stopped being used
- A misconfigured permission granting content editors more access than they need
Drupal core is heavily audited and maintained by a dedicated security team. The modules layered on top vary enormously in quality — that’s where the real risk sits.
How Do You Actually Secure a Drupal Site?
Patch on a schedule, not “when we get to it.” Drupal’s security advisories are rated by severity. Critical advisories should be applied within days. Subscribe to the security mailing list or use automated update monitoring so you’re not finding out about a vulnerability from an attacker instead.
Audit your module list quarterly. Every installed module — enabled or not — is a potential attack surface. Uninstall anything not actively in use. “We might need it later” is not a reason to keep an unpatched module on a production site.
Enforce two-factor authentication on admin accounts. Credential stuffing is one of the most common ways admin accounts get compromised, and 2FA closes that path almost entirely.
Review permissions by role, not by person. Over time, permission creep happens — someone gets temporary elevated access for a project and it’s never revoked. A quarterly role audit catches this.
Run behind a Web Application Firewall. A WAF filters common attack patterns before they reach Drupal at all, and buys time to patch when a new vulnerability is disclosed before you’ve applied the fix.
Keep backups that are actually tested. A backup you’ve never restored from isn’t a real backup. Test the restore process, not just the backup job.
What Does a Drupal Security Audit Actually Check?
A proper audit covers: core and module version status against current advisories, admin account and permission review, file system permission checks, exposed configuration or debug settings, and a review of custom code for common vulnerability patterns (SQL injection, XSS, unsanitized user input). This is different from a migration project — it’s a maintenance discipline, and it’s most valuable done on a recurring basis rather than once.
Security Is a Maintenance Problem, Not a One-Time Fix
The sites that get compromised are almost always the ones nobody’s been actively maintaining — not the ones with a fundamentally weak platform. This closes out the Drupal series: Drupal Migration Guide covers getting to a current, supported version, and Why Universities Choose Drupal covers why the architecture holds up at scale. Security is what keeps either investment protected long-term. For the broader picture across platforms, see Website Security & Maintenance: What Businesses Skip.
If your Drupal site hasn’t had a security review in the last year, or you’re not sure what version it’s running, let’s talk — a short audit is much cheaper than breach recovery.