If you're using Polyfill.io code on your site – like 100,000+ are – remove it immediately The polyfill.io domain is being used to infect more than 100,000 websites with malicious code after what's said to be a Chinese organization bought the domain earlier this year, researchers have said. Multiple security firms sounded the alarm on Tuesday, warning organizations whose websites use any JavaScript code from the …
Firefox 43 and Chrome 45 started supporting this thing called Subresource Integrity back in 2015 (Edge and Safari joined the party in 2018). Basically, use a specially-formatted hash in the 'integrity' attribute of the 'script' HTML tag. It allows scripts coming from third-party CDNs to be ignored if they're modified.
While I've just learned about it today myself, I can only hope that folks who do this for a living have a bit more of an ear to the ground for such revolutionary advances in security technologies as these.
I've just had a look at polyfill.io: and they only offer links to the major version. So the link given for version 3.111.0 is <site>/v3/polyfill.min.js So they could legitimately patch the script, without notifying you, and the url wouldn't change but the hash would now be different. Your site would instantly break without notification. (Or not, because these days it's only Safari being fused to iOS that causes compatibility problems.)
SRI is really for protecting one's own scripts from being mangled by someone at the hosting end when hosted on a third party server. You can apply them to third party scripts on a CDN, but you've got have a fixed link to the exact version, and be confident it won't be tweaked behind your back - breaking the hash.
So they could legitimately patch the script, without notifying you, and the url wouldn't change but the hash would now be different.
Isn't that the whole idea? The script was changed and so is not the one that you (presumably) tested your site with, so you no longer pull in the changed script, for security.
Whether it was "legitimately" patched or not is irrelevant, since you cannot know if the change was legitimate or not. It's a change and therefore a security risk until you've tested it and accepted the new version. If you can't keep up with testing changes, then download a known safe version & host it yourself.
I'd point out that a CDN could also legitimately patch the script with a version which isn't API-compatible and my site would also instantly break without notification. (Or it would become buggy for no discernible reason.)
The literature around SRI, such as Frederik Braun's (a co-editor of the draft) "A CDN that can not XSS you: Using Subresource Integrity" strongly suggests that untrustworthy CDNs are the target of the technology rather than untrustworthy web hosting companies. I don't disagree that it could be useful in ensuring that one's own code hasn't been altered. I find it strange to think that a hosting company wouldn't have access to both the document and its first-party resources, but I'm practically a lay-person when it comes to paying others to host content.
I'd personally rather face a broken website than allow one to be taken over by a supply chain attack, and that applies doubly when I'm the user of a site rather than someone involved in running it. I would consider it unconscionable for a bank's website to be using a third-party CDN for script dependencies without using this technology, for instance.
> this thing called Subresource Integrity
As Sora2566 pointed out, SRI won't work for the polyfill ("original as intended", not the dodgy version) stuff - it is specifically *designed* to return different content to different User-Agents, that's exactly the whole purpose of polyfill - i.e. for Firefox 1.0 and Firefox 2.0 and Chrome 2.0 and Safari 3.0 (all version numbers mentioned here are made-up) different content is returned to cater for missing functionality in those various browsers.
So therefore the *single* polyfill URL will have differing SRI hashes and so SRI can't be used.
The solution you describe is a solution to a problem that shouldnt exist. Host the scripts yourself, and there is one les problem. Please dont tell me the CDN is free, because its just not worth adding ONE more risk just to save basically nothing.
There are many ways to save traffic using a third party random cdn is not one of them.
I self-host everything, but I don't get visitors to my sites who aren't in my immediate geographical area.
CDNs are usually used to reduce load times by efficiently distributing resources from servers hosted more locally to visitors, and provide the benefit of allowing cached copies of those resources to be stored on the client device if multiple websites use the same URLs to access them.
While I agree with your philosophy, I disagree with your assessment of the tangible benefits of CDNs.
I didnt deny there are benefits to using a CDN.. im simply pointing out they introduce a risk which is too costly to any business when bad shite happens, and we have an example here thaat is unnacceptable.
Everything in life is a balancing game its not worth risking this damage just too save 100ms in load time.
Let me rephrase the question do you want to save 100ms loading that page if it costs half your info being sold all over the internet cuasing untold lost time resolving problems with banks and god knows who else for the rest of your life on a regular basis ?
The issue is that polyfill .io serves different JS per browser, so it's incompatible with SRI hashes. The solution is to either self-host it, or bundle the polyfills yourself. It's usually sufficient to have two JS bundles: One for old browsers (with all the polyfills required for the oldest browsers your app supports) and one for modern browsers (only polyfills required by browsers released in the last year or so).
I'm really not impressed. Websites should stop pulling in JS code from all over the internet. I get it, no need to reinvent all kinds of wheels lest we make them triangular, I'm all for code reuse. But dynamically pulling in stuff from places that could just become malicious over night is inexcusable. What was the discussion a couple of days back? Getting a sort of "food safety" standard for IT? Yeah, this is such a great example for it. Just as when preparing meals you need to make sure the ingredients are actually safe. So is there a possibility of getting anybody on the hook for poisoning your IT system because they employed lazy sods as web developers? Like getting compensation when the pre-packaged meal I (theoretically would) buy from a supermarket made me sick (more than usual) because some f**kwit thought it would be waaay cheaper to buy the green, worm riddled meat, and in a curry you would never taste that, just add enough chilli.
I have to admit I have never seen the polyfill.io domain, and I do block all JS per default and need to enable it on a case-by-case basis (and this has lead to me avoiding certain websites - you want scripts from more than 20 different places? What for?!). Really educational...
"I'm all for code reuse."
Me too, but the safe way to do it is to take a copy, check that it works, and then serve it from your own site.
Simply pulling it in by reference "so that you can benefit from any fixes they make in future" is simply asking for something like this to happen. It's placing the reputation of your site into the hands of someone who probably doesn't know who you are and certainly doesn't have a commercial reason to care, except possibly being slightly miffed that you are using their bandwidth.
I think it has to do with people (or web devs) generally not seeing websites as a piece of software, even though it is.
You need the same security procedures: source control/change management, supply chain management, etc.
Just the bare minimum would've prevented most issues here...
If you have to copy then your already broken... even if you are copying your code from your own company because tomorrow there will be dozens of copies of the same thing and that code will be broken or require a change... and naturally not all copies will be updated.
The proper solution is to refactor not copy.
Sound generally like a fair advice.
However, in case your team should develop modern Web applications, creating even a rather simple React app pulls literally thousands of 3rd party open-source packages as dependencies, sub-dependencies and sub-sub-sub dependencies into your codebase from the npm (etc) online repositories.
Good luck reviewing and knowing what all those thousand+ packages contain. From security perspective that development model is badly screwed.
It's not realty anything to do with JS.
The problem is a lack of respect for the same origin policy.
Why does my browser want to run scripts from googletagmanager.com when the browser bar clearly shows that I'm visiting theregister.com?
It's not the langauge of the payload that is the problem.
I defer to Douglas Crockford (2 mins) and Douglas Crockford (55 mins). And of course the photo with JavaScript: The Definitive Guide and JavaScript: The Good Parts.
Why does my browser want to run scripts from googletagmanager.com when the browser bar clearly shows that I'm visiting theregister.com?
That's easy - I have NoScript installed, and that domain is forbidden to serve up scripts to my browser, so it doesn't. I've yet to encounter a site that is broken as a result.
Agreed. Since the only purpose of googletagmanager is to spy on users, blocking it is a no-brainer. Along with googleanalytics and doubleclick — harmful garbage that exists on far too many sites. (And no, I don't buy the "we need analytics to serve you better" crap.)
There is a legitimate use for analytics, provided that the system used is trustworthy and is locally-hosted to protect user privacy (eg, locally hosted Matomo), and as long as the data that you get from this actually is reviewed periodically and actions are taken to improve the site content, layout, UI, etc, as a result. But sadly I suspect it is mostly the case that far too many sites mindlessly insert the Google Analprobe endoscope and all the rest of 'teh frEe sTufFz' because "all the other clueless web monkeys are doing it", and the site owner "thinks" it would be useful, but then rarely or never actually looks at it… «sigh»
I don't buy the "site improvement" stuff. There are plenty of successful design idioms out there, and you don't need to track your users to copy them.
Conversely, how often do you see a site do a complete layout redesign? How many sites spewing google analytics at you do this, ever?
I think the answers to those questions would enlighten you to how much of a bullshit factor applies to this argument.
I don't think I use any third party sites on my websites. Sometimes accidentally "remote google fonts" due to theme developers being stupid. I edit that out when I spot it.
I've been saying 25 years that it's stupid using 3rd party sites for content. Adverts and analytics should be served from same host too, or at least a server run by the same organisation.
My main reason for script or ad blockers isn't to block adverts but malware. More use today than AV for floppies or CDs.
I'd say the same, but with the provision that I'm not fine with ads that are intrusive. If I don't want to look at your ad, it's my choice, and forcing me to do so doesn't endear me to the product you are trying to flog to me.
I'm looking at you, unskippable 30 second video ads for the same thing EVERY SINGLE TIME, complete with loud sound, and tiny, teeny, microscopic close buttons on mobile apps.
Right. Magazine-style advertisements are fine, as far as I'm concerned. Anything with "multimedia" — animation, video, noise — is not fine. Anything that blocks actual content is not fine. Anything deceptive — made to look like something other than an advertisement — is not fine.
Exactly. Add to that anything that wants to run a script to show you an advert, because that's pretty much the number 1 malware vector.
I'd say that probably 99% of adverts out there cross at least one of these red lines, and that's why I block them all, both in the browser, and at the network level at home by blocking advertising domains.
NoScript now blocks polyfill.io on its badware risk list, just tried it. Problem is that most of us have allowed polyfill for a while now even, so how much risk were we exposed to? I usually do NOT allow polyfill on NoScript but a few websites do refuse to run unless you allow it, so this does *not* make me happy. I just blocked the domain on the entire office network.
And yet the online advertisers (and the sites beholden to the shiny) seem to think it's their god given right to expect you to run who knows what from who knows where out of their 764 "partners".
Remote scripts should be utterly disallowed, the only exception being for up to two specific domains mentioned in the DNS lookup for the primary domain (so as to allow stuff like CDNs).
Pulling random crap from all over, who'da thought that would go wrong. See icon.
> If you're using Polyfill.io code on your site – like 100,000+ are – remove it immediately
Will the purveyor's of LLMs ensure that content from Polyfill.io is removed from their models or is the damage now done and Copilot et al will generate code that has the backdoor to China already built in?
[ I apologise for breaking GodwAIn's law - sooner or later in a thread a post is either written by or references AI ]
I would have thought where an entity was demonstrably engaged in illegitimate or unlawful activities such as this, the urgent forced surrender of the DNS domain would be entirely justified.
The idea of downloading any old excrement from arbitrary sites on the internet and shoveling it into your clients' browsers (or have their browsers do this at your site's behest) must rank with some of the world's worst ideas.
While clever and powerfuI I was never comfortable with anything like ECMA-Script messing with a browser's DOM.
I never understood how web designers thought it was reasonable to treat external hosting of JS libraries on infrastructure that they don't own and don't pay for as some kind of public utility. People just slap in references to jquery or Bootstrap or whatever from random CDNs without a second thought.
These are big sites, run by "proper" companies/organisations. How are they so unprofessional?
How much do they pay? Nothing? Then they are freeloading, and also putting their work at risk of "sorry, sunsetting support kthxby!".
It's just mad that commercial organisations can just leech bandwidth from public service infrastructure. And get surprised when it stops working.
Saw this on my Techmeme feed. Lots of social media threads and news articles, for this type of news. The word "Chinese" is in the headline and/or in the very first paragraph of the article. This tells me it's a false flag. But people will gladly fall for the fear and war mongering every time. They have been subject to pavlovian programming for generations.
Pulling scripts from domains that they do not own for their shitty website, is an idiot, pure and simple, no ifs, no buts
But seeing as the majority do this I can only be led to the conclusion that the world is full of idiots.
Wait…. I already know this to be true just by people watching
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
