Drupal Security Best Practices, From an Agency That Cleans Up Hacked Sites

Most “Drupal security best practices” articles are written by people who have never been handed the login to a site that is already compromised. We have. A good share of the Drupal work that comes through our door is not a fresh build, it is a five-year-old site that nobody patched, running on a host nobody remembers picking. So this guide is ordered the way we actually work: triage first, then the steps that keep a clean site clean.

Drupal has a real security advantage over most CMSs. The security team is serious, advisories are coordinated, and the permission system is granular in a way WordPress only reaches with plugins. None of that helps if the site is two years behind on updates. The platform gives you a strong floor. What you do after launch decides whether you stay on it.

If you just inherited a Drupal site, do these four things first

Before any “hardening checklist,” find out where you stand. We run the same quick triage on every site we take over, and it usually takes under an hour.

1. Check the Drupal core version. If it is Drupal 7, read the next section now, because that changes everything. If it is Drupal 9, note that Drupal 9 itself reached end of life in November 2023, so you are also overdue.
2. Log in and open the Available Updates report at Reports, then Available updates. Red rows are security releases you are missing. That list is your first work order.
3. Count the contributed modules and ask which ones are actually used. We routinely find 15 to 20 modules installed and half of them switched off but still present in the codebase, each one a patch you owe.
4. Confirm a backup exists and that someone has restored from it at least once. A backup nobody has tested is a guess, not a safety net.

Only after that do the standard hardening steps make sense. Patching a site you do not understand is how people break checkout on a Friday afternoon.

The Drupal 7 problem nobody wants to say out loud

Drupal 7 reached official end of life in January 2025. That means no more security coverage from the Drupal Security Team for core or for most contributed modules. If you are running Drupal 7 today, “security best practices” does not really apply, because the thing that makes Drupal secure, the coordinated advisory process, no longer covers you.

There are paid vendor-extended support options that backport fixes, and they are a reasonable bridge if a migration is genuinely six months out. But they are a bridge, not a destination. We have seen D7 sites limp along on extended support for two years while the real cost, a delayed rebuild, kept growing. If you are on 7, the honest best practice is to plan the move to Drupal 10 or 11. We wrote up how we approach that in our Drupal migration service, and it is the single biggest security decision a D7 owner can make.

Updates: automate the boring ones, gate the risky ones

Unpatched software is behind almost every Drupal site we have cleaned up. The famous ones, Drupalgeddon in 2014 and Drupalgeddon2 in 2018, both had patches out before mass exploitation started. The sites that got hit were the sites that waited.

On modern Drupal we turn on the Automatic Updates module for core security patches on smaller sites, where the risk of an unattended update is low and the risk of a forgotten patch is high. For larger or revenue-critical sites we do the opposite: updates run through a staging environment and a deployment pipeline, never straight on production. Auto-updates are a safety feature for the site that would otherwise never get touched. They are a liability on a complex site where one bad release can take down a custom integration.

Either way, the rule is the same: core and contrib security releases get applied within days, not “next quarter.” Subscribe to the security advisories from drupal.org so the alert reaches a human, not just a dashboard nobody opens.

The contributed modules we actually install

Generic lists tell you to “use security modules.” Here are the specific ones we put on most client sites, and why.

• Security Review audits the site against common misconfigurations: dangerous file permissions, executable PHP in uploads, overly broad roles. It is the first module we install on a takeover because it turns “I think this is fine” into a report.
• Password Policy enforces length and complexity and can force resets. Most breaches we see start with a weak admin password, not a clever exploit.
• Two-factor Authentication (TFA) on every account that can edit content or configuration. This one change stops the majority of credential-stuffing attempts dead.
• Seckit adds the HTTP security headers, content security policy, clickjacking protection, and similar, that a default install leaves off.
• Shield puts HTTP basic auth in front of staging and pre-launch sites so an unfinished build never gets indexed or poked at.

Note what is not on the list: a dozen overlapping “all-in-one security” modules. Every module you add is more code to patch. Each one of these earns its place. Adding ten more would make the site less secure, not more, because the attack surface grows with the codebase.

Permissions, the part everyone gets lazy about

Drupal’s permission system is one of the best reasons to use it for sites with real editorial teams or sensitive data. It is also the part people configure once, in a hurry, and never revisit. The default failure mode is giving editors the administrator role because it was faster than building a proper one.

Grant the narrowest permission that lets someone do their job. An editor needs to publish articles, not install modules or run updates. Watch the permissions flagged as security-sensitive, the ones marked with a warning on the permissions page, because several of them, like “administer filters” or “use PHP for settings,” can be turned into full site takeover by a single compromised account. Review roles when staff change. An ex-contractor’s active admin account is a door you left open.

Hosting and the layers above Drupal

A lot of “Drupal security” is not really Drupal. The site lives on a server, behind a network, in front of a database, and weaknesses at any of those layers undo good application hygiene.

• Run a current, supported PHP version. Drupal 10 and 11 need recent PHP, and an outdated PHP build is its own security hole regardless of how clean your Drupal is.
• Force HTTPS everywhere and redirect plain HTTP. Free certificates from Let’s Encrypt removed the last excuse years ago.
• Put a web application firewall in front of the site. Cloudflare’s free tier or a managed Drupal host like Pantheon or Acquia gives you one without standing up your own.
• Lock down file permissions so the web server cannot write to code directories, and make sure the settings.php file is not world-readable.

Where we land

Drupal earns its security reputation, but the reputation is about the platform, not your specific site. Stay on a supported version, apply security releases within days, keep the module count honest, and use real roles instead of handing out admin. Do those four things and you have already beaten most of the sites that get compromised.

If you are staring at a Drupal 7 site, an out-of-date Drupal 9, or a takeover you are not sure about, that is exactly the work we do. We run the triage above, give you a plain-language report, and tell you whether you need a few patches or a migration. If you are still weighing Drupal against other platforms, our take on Drupal versus WordPress covers where each one fits.

Universities carry extra security weight: accessibility law, student data, and dozens of department sites. See how we approach campus builds in our Drupal for higher education guide.

Still weighing whether the platform has a future before you invest? We wrote a no-spin take in is Drupal dead in 2026, from the perspective of a shop that builds on both Drupal and WordPress.

For the wider toolkit beyond security, see the Drupal modules we actually install on client projects.

If you would rather have someone check the whole site for you, our Drupal security audit reviews advisories, permissions, modules, and server config, with a rated report and an optional fix tier.