I'm sure many of you have heard of the recent issues around the Polyfill supply chain attack. In short, a popular domain used for loading JavaScript, polyfill[.]io, recently changed hands and after that change in ownership, the new owners started to serve malware with the JavaScript. Here's how Report URI has responded so far, and our plans for future action.

Report URI

Report URI has been helping our customers deploy strong application security controls, like Content Security Policy, for almost 10 years. As part of that journey, we have developed features and capabilities that allow us to provide assistance in scenarios such as the one we currently find ourselves dealing with. In order to respond more specifically to the polyfill[.]io threat, we've made the following changes.

Threat Intelligence

Using a blend of our own internal Threat Intelligence feeds, and a selection of external Threat Intelligence data that we subscribe to, we launched a powerful new feature back in 2022 and only months later, we expanded that feature.

With the ability to look for a known Indicator of Compromise (IoC) within your telemetry and raise that within our UI, website operators can see if their site began loading JavaScript from questionable sources. Over the weekend, Report URI started flagging the use of the polyfill[.]io and cdn.polyfill[.]io domains as an IoC and any such reports will now attract the appropriate warning in our UI.

Customers with our Threat Intelligence product can head to their CSP -> Reports page right now and check the "IoC Filter" to see if they have any instances of loading JS from polyfill[.]io or any other known source of compromised JS.

Analysing your Content Security Policy

Alongside this expansion of our existing capability, we've also added a new capability. Given the unique nature of the current polyfill[.]io threat, we've added a new detection to our report ingestion pipeline. Previously, our analysis was focused on resources that were reported as being blocked on your site. Your CSP would define resources that were allowed to be present, and the browser would send a CSP Violation Report for any resources that were not permitted to be present. This is the standard functionality of Content Security Policy.

The problem we now face is that if you have allowed polyfill[.]io or cdn.polyfill[.]io in your CSP, the presence of those resources on your site would not trigger a Violation Report. You've authorised those resources to be present, so as the browser sees it, there is nothing to report on. Fortunately for us, one of the pieces of information that a browser will send us in the Violation Report is a copy of the original CSP your site sent along with the page. Here is an example JSON payload that we would receive:

By analysing the provided copy of your original policy, we can determine if you are permitting dangerous resources to be loaded on your site. Given that the polyfill[.]io and cdn.polyfill[.]io domains were previously trusted, it's possible that they are present in your CSP and now pose a threat. Such Violation Reports that indicate your CSP will allow the loading of dangerous resources will now be flagged as an IoC.

As you can see, the blocked resource in this particular case is not what is attracting the warning, but instead, it's the presence of cdn.polyfill[.]io attracting the warning!

Customer Outreach

Over the past few days we've monitored our telemetry to better understand the risk this issue poses to our customers and how we might best respond. Along with the above changes that are now available to all customers on a suitable plan, we are also beginning an outreach campaign to those customers that we feel are most at risk. Those customers are mostly on our Enterprise tier and you will be hearing directly from your account contact starting today.