5 Basic Rules to Keep your Website Dependencies Secure
Drupal is known as one of the most secure open-source CMSs. Thanks to the community's high standards and excellent automated tools, it offers the highest level of protection against modern threats. However, as a site maintainer, you should always be aware of security vulnerabilities that can be caused not only by Drupal but also by its dependencies.
The last decade has been dominated by package managers. PHP software development was redefined by Composer. Every modern project, including Drupal, has hundreds of external dependencies. We rely on the work of many independent developers and companies. The question is: how do we trust their code? How do we make sure we stay away from malware?
Vectors of Attack
First, you have to realize that there are many possible attack vectors:
- The attacker can take control of a repository and release a modified version with malicious code. It doesn't have to be a hostile takeover. The maintainers may simply sell their projects. There have also been cases where repositories have been moved or deleted, and their original namespaces reclaimed on GitHub. This type of repo-jacking has been possible since 2018 and was disabled in 2022 after reports of major security breaches.
- It is possible to hijack a Packagist account. In May 2023, a hacker using the pseudonym "neskafe3v1" managed to take over four accounts containing PHP packages used by 500,000 sites. Fortunately, the attacker didn't do any damage other than to mark his presence in the package credits.
- Any external domains referenced by packages can be hijacked and maliciously modified. This recently happened to the polyfill.io CDN, which was hijacked by a Chinese company. Thanks to the quick response of the domain provider, the risk was minimized. However, many Drupal modules needed security patches. In this type of attack, even old versions of the package can be affected as long as they use a malicious CDN.
- The Composer itself may be the source of the vulnerability. It is well-tested and maintained, but there are still many new security issues. If you look carefully at its changelog, you will notice a lot of critical vulnerabilities found during audits.
- You may unintentionally break their security if you define custom patches for your dependencies.
Site Security Ground Rules
As you can see, there are many ways to hack the supply chain provided by Composer. You can prevent most of these attacks by following these five basic rules:
1. Keep Your Dependencies Updated
You will need to run the composer update action periodically to keep your packages up to date. In Drupal, this command must be followed by running database updates to migrate existing content and configuration.
It is also important to monitor the report generated by the composer outdated command, which shows major update opportunities. In most cases, your composer.json file will limit major updates (such as from 2.0 to 3.0) to avoid introducing breaking changes. It is your responsibility to apply these updates manually. Composer will warn you if the major version you are using is not supported.
2. Keep Your Composer Up-to-Date
Composer receives many security fixes and improvements, so you should update it as often as possible. This seems like obvious advice, but I have seen numerous projects where Composer was updated once every few years. Remember, just because you use something locally doesn't mean you're safe from outside attacks. Most package manager vulnerabilities come from the Internet when the supply chain is compromised.
3. Review Your composer.json from Time to Time
If you care about your site, you should be aware of the contents of your composer.json file. It is a good habit to check it from time to time:
- Check for updates blocked by your version constraints (see rule #2).
- Check for unused Drupal modules and packages. The more dependencies you have, the more threats you face. Remember that removing Drupal modules from Composer must be preceded by uninstalling them.
- Check if patches are still needed and if they work at all.
- Run a composer audit to see if any of your packages need urgent attention.
Big organizations usually manage a whitelist of allowed modules that are proven safe. This process costs a lot of time and effort, but it prevents developers from using unsafe dependencies.
4. Use Automated Tools
I already mentioned the Composer audit command as a tool to help you maintain your dependencies. It is not the only tool available on the web. You can also use the binary executable from https://github.com/fabpot/local-php-security-checker, which will check your dependencies against the https://github.com/FriendsOfPHP/security-advisories database. This also works fine for Drupal and its modules.
5. Follow the Security News
It is important to at least follow Drupal's security advisories. The community does a great job, but updating the dependencies is sometimes not enough. The advisories may contain instructions on how to fix your code or patch the dependent packages. Always read them carefully and apply any fixes to the project.
What If the Security Breach Was Announced?
When the breach is announced, read all the information carefully and see if it applies to your project. Apply any necessary updates and perform security audits. Also, make sure that your custom code doesn't contain this vulnerability.
You need to be aware that not all packages will be updated immediately after the vulnerability is announced. They may have dependencies that are not actively maintained. In some cases, you can search the vendor and contrib directories for malicious URLs or insecure code. This was highly recommended after the hijacking of the CDN domain polyfill.io, which was used by many minor packages. Fortunately, Drupal modules are usually fixed in the blink of an eye.
To Sum Up
Keeping your Drupal site secure takes some time and knowledge, but it is not that difficult if you follow the basic rules. Frequent updates and audits will definitely pay off. Nothing is worse than catching up on updates after a few years of avoiding them, especially if you are hurrying to patch some critical vulnerabilities.
Also, you don’t have to be a security expert to follow the advisories and apply them. Soon enough, you will find that the Drupal community cares about your safety, and all the information is well explained.