Making the polyfill.io vulnerability a thing of the past for Drupal

Recently, there has been a flurry of activity as the Drupal community has scrambled to mitigate a vulnerability caused when the company that bought polyfill(.io) started injecting malware into the scripts returned by the service, referred to as a supply-chain attack. If you own or manage a Drupal site and you haven’t heard about this, the quickest ways to fix it are:

• Update all of your Drupal modules (yes that can be quick if your site is regularly maintained), or
• Put your site behind Cloudflare who have implemented automatic mitigations

The primary problem here is that polyfill(.io) was previously a trusted resource, and now it is not. Many pundits in the web sphere are predicting that this will increasingly be a point of vulnerability for open-source software. A service starts seeing less traffic and is less attractive for the owner to maintain, it gets sold (unknowingly) to a bad actor, and mayhem ensues.

So how do we fix it?

Use trusted services

For each programming language or framework, there is typically one primary library registry or repository which is the most trusted source of code. For Drupal it’s git.drupalcode.org, for PHP it’s packagist.org and for JavaScript, it’s npmjs.com – not polyfill(.io) – I’m putting the parent domain in brackets so your browser doesn’t try to take you there.

The polyfill service filled a need for sites by automatically providing functionality for older browsers like Internet Explorer – a need that is gradually reducing and also being solved by newer methods like employing Babel to compile code that can be run by a set of browsers chosen by the site developers. Babel’s code can all be retrieved from npm and it runs on the developer’s machine or in a CI/CD pipeline. This means there’s no third-party website involved that could just suddenly switch on malware in the way that polyfill(.io) did.

Frontend Bundler Initiative

In a recent post we talked about a new community initiative that we’re spearheading which is intended to make it possible for Drupal project developers to compile all contributed modules into a set of libraries that Drupal can then use, without resorting to CDNs and services to supply end-user JavaScript. If this initiative is widely adopted, it will make supply-chain attacks much more difficult to execute and will vastly reduce the surface area available for the attack as projects are updated periodically instead of fetching code from a service in real-time.

If you’d like to stay abreast of what’s happening please join us in the #frontend-bundler-initiative channel in Drupal Slack.