In light of the recent polyfill.io incident, we sat down to speak with JavaScript expert Simon Wijckmans, on how the incident occurred and what can be done about it. Simon is the founder of c/side, a cybersecurity company with tools for monitoring, optimizing, and securing vulnerable browser-side third-party scripts, and has previously worked at Cloudflare.

devmio: Could you talk a little about your career journey and what led you to founding c/side?

Simon Wijckmans: I was originally born in Belgium. While growing up, I realized that schools did not provide me enough access to the topics I cared most about (most notably, technology, engineering, and business). There was a loophole, which I went ahead and used at 16: I built a team to teach me the required knowledge for my degree and built my own model for important subjects—like computer science, economics, and law—not included in the curriculum. This path gave me the degree I sought, but it also programmed me to pursue a life of continuous learning.

I then joined Microsoft as a contractor at 17, later full-time. Afterwards, I joined Cloudflare and became a Product Manager. About three years later, I joined Vercel as a Senior Product Manager working on their enterprise products. Finally, I joined Hydra (a Y Combinator startup) as Product Lead before now running my own entrepreneurial journey with c/side.

I tried to shape my journey so that I could learn from different-phased companies (startups and enterprises) and in various roles (both internal and customer-facing). Starting my own business was always the plan. I had many side projects over the years, but I wanted to gather a ton of experience along the way so that I felt comfortable and familiar with hard situations. A decade in, the right opportunity presented itself and c/side was founded.

devmio: Given your expertise in JavaScript security and your experience at Cloudflare, how do you assess the severity of the recent Polyfill attack?

Simon Wijckmans: Unfortunately, this high-profile attack is the perfect example of what we’re trying to solve. First and foremost, it shows that third-party scripts on websites can have a profound impact and these sites would never know. Websites are sailing completely blind on the client side, and it’s incredibly dangerous to expose your users to such attacks.

Secondly, it showed that scripts are sticky. About half a million websites (and possibly more) still had the Polyfill script on their site, where realistically the script is there only to address old browsers used by fewer than 1% of users (and decreasing every day). But old scripts that aren’t removed become a permanent risk factor, as this major incident showed. Not only mom-and-pop shops with sites created by small agencies had Polyfill still on it, but even Hulu, The Guardian, Intuit, and other very large sites still had it embedded.

Thirdly, and this is the scary part, this attack had a relatively low impact. That won’t always be the case. Here, a visitor being redirected to a betting site or adult content site is a very simple and visible attack, but the bad actors could have easily injected a script with far less visible and dangerous intentions. A malicious script could be designed to activate only within a PWA mobile app, or a crypto-mining script might trigger only when the browser detects an IoT device with limited debugging capabilities. As much as this was already scary and caught a lot of headlines, the internet by and large got lucky. This could have been way more severe, and nothing is stopping a bad actor from trying the same type of attack again. We must continuously monitor our entire supply chain, including the client, without just relying on sampling.

“We must continuously monitor our entire supply chain, including the client, without just relying on sampling.”

devmio: What specific vulnerabilities in the JavaScript ecosystem were exploited by the attackers in the Polyfill incident?

Simon Wijckmans: Polyfill was originally an open-source project allowing websites to use modern JavaScript features in older browsers like Internet Explorer. Eventually, this largely became unnecessary as almost all users have moved to more modern browsers. The open-source code itself was actually fine, but the domain to reference the script, Polyfill[.]io was purchased by a Chinese company called Funnull. Funnull then altered the code served through that domain, which redirected a percentage of users to adult and betting websites based on their User-Agent.

The problem is that thread feed vendors are slow to catch up. For days after the news broke, many didn’t update their registries and still flagged this (and other domains used in the attack) as safe.

devmio: Beyond redirection attacks, what other types of malicious activities can be achieved by compromising JavaScript code?

Simon Wijckmans: A simple redirect like this is one of the most simple outcomes. But indeed, much more is possible. People are likely most afraid of stealing personal information, like login credentials or even credit card details as was seen in the infamous 2018 British Airways attack. (We actually now own the domain that was used there and turned it into an educational website that outlines the entire attack for anyone who wants a deep dive on that attack: baways.com.)

But technically, anything that is possible in the browser can be achieved through this attack vector. In the BrowseAloud supply chain attack, the malicious actors injected the CoinHive cryptocurrency mining script into this hijacked script.

The sky truly is the limit in these types of attacks, and more is possible every day as we make browsers more capable and complex.

devmio: How can developers effectively identify and mitigate risks associated with third-party JavaScript libraries and CDNs?

Simon Wijckmans: For starters, thread feeds are definitely not the way. They fundamentally “don’t know what they don’t know” and are playing catch-up each time news of an attack breaks.

We believe the only way is to check the full payload of the code before it’s loaded in the browser of the user every time it gets loaded. Only then will you be able to see exactly what’s going on. We have engineered c/side to do this in a proxy. Only when it’s safe are the scripts served to the users. Through some clever tricks and engineering, it doesn’t even cause latency.

You can do this in CDNs too, but that isn’t 100% foolproof either. You only need to go as far back as 2021 to the cdnjs vulnerability to see how that can go wrong too. Over 12% of all websites on the internet inject at least one script through cdnjs, illustrating the severity of the problems should it go wrong.

We should not trust that what we get from a third-party is de facto safe. We should verify, as everyone can have a bad day and bad actors are on the lookout for every opportunity they can get.

devmio: What role does developer education and training play in preventing these types of attacks? How can organizations build a robust security culture to address the evolving JavaScript threat landscape?

Simon Wijckmans: Attacks like these keep happening and the developer community is increasingly aware of this issue, but security leadership often isn’t. However, the developers are usually not the ones that want to add these scripts. They are asked by other teams like Marketing, Legal, HR, Data, etc. to add scripts. Lacking governance to implement a script is a major issue as for many companies adding a third-party script is a gray area in their processes. We hope that using a service to track client-side behaviors will soon become a basic no-brainer to protect users. With a tool like what we built, you can knock this off the list in minutes and no longer need to worry about it.

“Attacks like these keep happening and the developer community is increasingly aware of this issue, but security leadership often isn’t.”

devmio: With the increasing complexity of web applications and the growing reliance on JavaScript, what do you see as the biggest challenges for developers in securing their code?

Simon Wijckmans: Browsers are rapidly evolving. Staying on top of all the security risks of an evolving platform that at the same time is actively being adopted for more things is very, very hard. The risks of client-side attacks are evolving at a fast pace.

One interesting development is that these client-side attacks are coming to mobile applications. With the creation of Progressive Web Apps (PWAs), suddenly websites are turned into web apps—and therefore the entire client-side attack surface of a browser now applies to a mobile app.

The supply chain in general is known to be a big problem in shipping secure code, but many in leadership are not yet aware of the unmonitored risks client-side. The current state of supply chain security is a bit like a leak in a tire: it doesn’t matter if you close down five holes, if there are two big holes left, you’ll still end up with a flat tire. Attackers will shift their attack to an area that is least secure.

devmio: With the rise of AI, I suspect these attacks will grow more sophisticated. How do you see AI impacting JS or other related security attacks?

Simon Wijckmans: AI has made it easier to get complicated actions done better and faster. This is true for good code, but also for malicious code. I’d suspect the amount of attacks will only go up, especially in the short-to-mid-term as companies are not paying enough attention to this attack vector. For client-side security, because of how many detection mechanisms work, AI is a very severe threat. Slightly altering the code so that it doesn’t match a bad hash while still performing the same actions has become a lot easier.

“I’d suspect the amount of attacks will only go up, especially in the short-to-mid-term as companies are not paying enough attention to this attack vector.”

devmio: Given the increasing frequency and sophistication of cyberattacks, developers find themselves at the forefront of defending against digital threats. What practical steps can developers implement in both their professional and personal lives to mitigate risks and protect sensitive information? What specific security measures can be implemented at the application level to protect against supply chain attacks?

Simon Wijckmans: One needs to look at the entire web supply chain, and there are several things to secure outside of third-party scripts.

Firstly, use a tool to monitor your client-side fetched scripts. The fetching itself, the changes of sources, the change in exfiltration paths, the changes in code…that all needs to be accounted for. If you can self-host the scripts, that is one less potential issue. If it uses the same infrastructure as the rest of your site, you have more control.

If you must add a third-party domain, ensure proper DNS security practices are in place. Then make sure they are securing the TCP/IP connection as well as the now standard SSL/TLS handshake. RPKI monitoring and Certificate Issuing monitoring can save the day here. To prevent Cross-Site Scripting (XSS) attacks, properly encode any user-generated content in server responses.

If inline scripts are necessary, use a nonce (a one-time token) in the script tag. CSS expressions can execute code in the browser context, potentially leading to security vulnerabilities, so make sure to cover that. If inline scripts are not necessary, add a CSP header to the site to prevent inline scripts.

Also, set suitable cache directives to avoid storing sensitive information in the cache—especially sensitive pages or one-page applications where scripts are often running site-wide.

If applicable, service workers can intercept network requests, manage caching, and enable offline functionality. Ensure that resources loaded from cross-origin sources are not able to interfere with the rendering of your site and implement anti-CSRF tokens in forms to guard against Cross-Site Request Forgery attacks.