What We Learned From the Polyfill Attack

NPM is notorious in the web dev world for some pretty nasty attacks, and we all know that the only thing heavier than the node_modules directory is yo mama.

So one question arises - if NPM is terrible, and CDNs can be so easily compromised, what can you do to actually build reliable, safe software for the web.

Of course, I am asking this in the context of real world projects with tight deadlines and annoying project managers, so answers like “don’t use any 3rd party libraries” aren’t really realistic.

What is the Polyfill attack

Before exploring some security best practices, let’s spend 30 seconds to make sure we all are on the same page, and we understand the details of this attack.

Most software today isn’t developed from scratch. We rely on a range of third-party resources as building blocks for our applications. For the web, the chances are you are either using Node and NPM to manage these resources locally, or you download 3rd party scripts directly via a public URL.

The Polyfill attack, which, by the way, targets a library you shouldn’t be using in this day and age, falls in the second category.

Back in February 2024, a Chinese company acquired the polyfill.io domain and started distributing malicious code via their CDN subdomain. The attackers jumped through some hoops to cover their tracks, but the key takeaway is this:

Once developers decide to trust a specific library and they are including it in their app, that 3rd party code can do pretty much anything on the page.

So this brings us to one of the most important lessons. I don’t want to sound like a crazy person but… don’t trust anybody.

The JavaScript space is filled with absurd libraries which are racking millions of downloads every month. This is open source software, and everybody has a price so no one can guarantee that any of these widely used libraries will not be compromised in the future.

Second, you should really consider using NPM instead of downloading from a CDN when possible. Sure, CDNs come with a lot of benefits, and there are a lot of well-known reputable Content Delivery networks with strong security practices.

However, when downloading directly from the web, there is no version control or content integrity, so the code served today could be different from the code served tomorrow and you wouldn’t know it.

NPM has its faults, but the workflow it proposes allows you to plug in some additional steps. Once you downloaded a library locally, you can use package lock files to lock down the version and avoid unwanted changes. With the code available locally you can also run audits and security checks.

Furthermore, Node offers the “— ignore-scrips” flag when installing packages, which enhances security by mitigating the risk of executing potentially malicious code embedded in npm packages.

npm install axios --ignore-scripts

It is also worth mentioning that web development is known for the lack of security standards, and platforms like Deno and package managers like JSR are trying to mitigate some of the known problems.

If you feel like you learned something, you’ll probably find some of my other videos interesting as well.

Until next time, thank you for reading!