How to Secure Drupal Against Common Vulnerabilities
A secure Drupal website depends on regular maintenance, sensible configuration and careful handling of user input. Core software, contributed modules, themes, hosting controls and editorial workflows all affect the attack surface. A weakness in any one of these areas can expose customer data, deface pages or give an attacker a path towards the server.
This matters for Australian organisations of every size. A small community site in Hobart can hold as much personal information as a larger project in Sydney, while online retailers in Melbourne may process payments and account details every day. Drupal security is therefore a continuing operational responsibility rather than a once-only installation task.
| Risk area | Typical exposure | Primary control | Useful Drupal practice |
|---|---|---|---|
| Outdated core or modules | Known exploits and privilege escalation | Patch promptly and monitor advisories | Composer updates, security releases and staging tests |
| Weak accounts | Account takeover and administrative abuse | Strong passwords, MFA and least privilege | Role review, SSO or MFA module, protected admin paths |
| Malicious input | XSS, SQL injection and unsafe output | Validation, filtering and prepared queries | Form API, Twig auto-escaping and trusted APIs |
| File uploads | Web shells, malware and unauthorised files | Restrict types, storage and execution | Private files, upload validators and web-server rules |
| Misconfiguration | Data leakage and bypassed access controls | Harden production settings and hosting | Trusted hosts, secure cookies, logging and backups |
Keep Drupal Core And Dependencies Current
Drupal publishes security advisories for core and contributed projects through its security team. A reliable maintenance process starts with knowing exactly which Drupal version, modules, themes and PHP packages are deployed. Composer makes this inventory easier by recording dependencies in composer.json and composer.lock, helping teams reproduce the same codebase across development, staging and production.
Apply security updates promptly, but do not update directly on a live site without a rollback plan. Test changes on a staging copy, check custom modules and review important workflows such as login, checkout, search and editorial publishing. For many Australian small businesses using managed hosting, a monthly maintenance window is practical, but critical security releases may need attention much sooner.
Use composer outdated --direct to identify direct dependencies, and review Drupal security advisories rather than relying only on version numbers. A release may contain a security fix even when the visible feature set has barely changed. Keep PHP, the database engine, web server and operating system supported as well; Drupal cannot compensate for an obsolete server stack.
Automated backups should accompany every update process. Store at least one backup away from the web server, protect it with access controls and test restoration periodically. A backup that has never been restored is only an assumption about recoverability.
Control Accounts, Permissions And Administration
Most Drupal users should have the minimum permissions needed for their work. An editor may create and publish content without administering modules, changing user roles or viewing configuration exports. Review roles regularly, remove dormant accounts and avoid sharing administrator credentials. Named accounts create an audit trail that is far more useful than a generic “admin” login.
Protect administrative accounts with long, unique passwords and multi-factor authentication. Where an organisation already uses an identity provider, SSO can simplify joiner and leaver processes, although it must be configured carefully. For smaller sites, a reputable MFA module can add a second factor to privileged accounts. Rate limiting and account lockout controls also reduce password-guessing attacks.
Drupal’s permission system is powerful, but it is easy to create unintended access through overlapping roles. Test permissions as a normal authenticated user, an editor and an anonymous visitor. Pay special attention to permissions for viewing unpublished content, administering users, using developer tools and accessing reports that may contain sensitive information.
Administrative access should use HTTPS, including on staging and internal environments. Secure, HttpOnly and SameSite cookie settings reduce session theft and cross-site request risks. A reverse proxy or web application firewall can restrict access to /user/login and administrative routes by network where that fits the organisation, but such controls should supplement Drupal permissions rather than replace them.
Prevent Unsafe Input And Output
Drupal’s Form API provides validation and sanitation mechanisms that are safer than processing raw request values manually. Custom code should use Drupal services and database APIs, including placeholders for query values, instead of concatenating SQL strings. This reduces SQL injection risk and makes custom modules easier to review.
Cross-site scripting commonly appears when untrusted text is printed into HTML, JavaScript or attributes without the correct escaping. Twig templates escape output by default, but developers can bypass that protection with filters such as |raw. Treat raw output as an exception requiring a clear reason, and use context-appropriate escaping whenever values are inserted into markup, URLs or scripts.
Cross-site request forgery is another concern for forms and administrative actions. Drupal’s form system includes token protection for many operations, but custom routes and controllers still need careful access checks and request validation. A route should verify both that the user is allowed to perform an action and that the request is intended for that action.
Contributed modules should come from trusted sources and be kept lean. Every additional module increases maintenance obligations and may introduce insecure defaults, vulnerable dependencies or excessive permissions. Before installing a module, check its maintenance status, security coverage, issue history and compatibility with the site’s Drupal branch. Practical Drupal administration guides, such as those collected on Drupal administration guides, can help site owners understand configuration choices before deploying them.
Harden Files, Configuration And The Server
File upload fields deserve special attention because an uploaded file can become an attack tool if it is executable or later interpreted in an unsafe context. Restrict extensions, MIME types and file sizes according to the business requirement. Do not allow anonymous visitors to upload files unless the workflow is essential and strongly controlled.
Use Drupal’s private file system for documents containing personal, financial or commercially sensitive information. Public files may be served directly by the web server and can be indexed or shared if their URLs become known. Private files should be delivered through Drupal access checks, with permissions defined for the relevant content and user roles.
Production sites should have error display disabled and should avoid exposing stack traces, environment variables or database details to visitors. Keep detailed logs protected from public access, and send security-relevant events to a monitored location where feasible. Check that settings files, backups, database dumps and Composer files cannot be downloaded through the web server.
Drupal’s trusted host patterns help prevent host-header abuse by defining the domains the site is permitted to answer. Enforce HTTPS with a valid certificate, redirect HTTP safely and configure reverse proxies correctly so Drupal recognises the original secure connection. At the hosting layer, disable directory listing, separate the database from public access and prevent PHP execution in upload directories.
Australian organisations should also consider the Privacy Act 1988 and the Notifiable Data Breaches scheme. If a compromise may expose personal information and is likely to cause serious harm, the organisation may have notification obligations through the Office of the Australian Information Commissioner. Good Drupal hardening does not replace legal advice, but it reduces the chance that an incident becomes a reportable data breach.
Build A Routine For Detection And Recovery
Security monitoring should identify unusual behaviour before it becomes a serious incident. Review failed logins, unexpected account creation, permission changes, new modules, altered configuration and unexplained file changes. Drupal logs are useful for initial investigation, while web-server, hosting and identity-provider logs can reveal activity outside the application.
Use vulnerability scanning carefully. An external scanner may identify missing headers, exposed services or outdated software, but it may not understand Drupal permissions and workflows. Run authenticated checks in a controlled environment, confirm findings manually and avoid aggressive scans against a production site during busy periods. The Australian Cyber Security Centre’s Essential Eight is a useful reference for broader controls such as patching, backups, application control and multi-factor authentication.
Create an incident plan that defines who can disable accounts, take a site offline, contact the hosting provider and assess affected data. Keep emergency contact details current, including the web agency, managed host and payment provider. A retailer serving customers across Brisbane or Perth may need to coordinate outside normal office hours, so responsibilities should not depend on one person being available.
Practical Checks For Each Maintenance Cycle
- Review Drupal core, contributed modules, themes, PHP and server security updates.
- Test backups by restoring a recent copy into an isolated environment.
- Audit administrator accounts, roles, permissions and inactive users.
- Check public files, private files, logs, configuration exports and upload restrictions.
- Review suspicious login activity, security advisories and unexpected configuration changes.
Australian businesses should also examine their third-party relationships. A local hosting provider may offer daily snapshots, malware scanning or a managed firewall, but the contract should state retention periods, restoration support and incident notification timing. Payment, email marketing and analytics services need their own access reviews because a compromised integration can expose the Drupal site indirectly.
Finally, record each maintenance action and its result. A short register showing patch dates, backup tests, permission reviews and incident exercises creates accountability and makes future troubleshooting faster. Regular security work is easier to sustain when it is treated as part of normal website administration, alongside content publishing and performance checks.