Security and privacy risks of public JavaScript CDNs
httptoolkit.com
httptoolkit.com
I know this is not how most sites operate these days, but consider that your visitor wants to visit you and getting your website. Whenever you embed stuff from other servers you not only gift away your user-data and breach their trust, you just doubled your attack surface and lowered the reliability of your site. And for what exactly?
My suspicion is that developers find it easier to paste a CDN include than downloading the file and including it themselves. Because performance my ass.
That's a bit like that cookie notice thing. Guess what: if you don't collect personal data and store it on your users computer, you don't need to ask them for consent and suddenly your site looks a lot cleaner and needs to deliver less data.
The vast majority of people do not care nor even think about this. They might instead for example find it useful to see Twitter embeds right inline of the page rather than load the site externally.
I find it useful, but I find it even more useful when the tweet content is copied to the site instead of embedded because it's still there when the tweet is deleted or Elon decides it's not profitable to allow embedding tweets.
Sure they don't know the details, but they know it sucks.
If a font is not used at all it is not loaded, that's why subsetting and loading with unicode-range works as an optimization.
I definitely agree that you should not use a these public CDNs though.
But one image can easily exceed it.
It's best to reduce the size of images, but even doing that everywhere won't make the bloat of mostly useless JS any better.
Well, no. Loading just one file from an external domain (CD or not) equals one additional DNS resolution (and SSL handshake), equals a lot of wasted time, often blocking.
Self hosting scripts, css and fonts would be one the very first things I'd do.
When the CDN was slow, every user noticed and thought your website was slow.
You gave away free analytics and made your website worse, there wasn't even a trade off.
> if there ever was a cache hit because a user visited one site then yours that coincidentally used the same CDN and query version
This is not how modern browsers work anymore, and the phrasing makes think it isn't a rhetorical statement?
> the user did not notice.
... That's kind of the whole point; they didn't think the website was slow. They didn't think anything. The website opened and then they went on using it. You do understand this, right?
It's in response to the "you should totally direct link your jQuery from this CDN" propaganda.
> That's kind of the whole point; they didn't think the website was slow. They didn't think anything. The website opened and then they went on using it. You do understand this, right?
The marketing pitch included "faster".
There's probably a dozen versions of react that make up a healthy 20% of the web.
> and in a short enough time to not suffer a cache eviction
These assets are cached by version. They can be basically immutable forever, with maximum expiration.
As commented elsewhere, you don't even have to give away free analytics. Just set a referrerPolicy on your <script> tags. And add subresource integrity to protect from the CDN being compromised.
I get that the Storage Isolation needs forced us to blow up the real awesomeness of CDNs. I'm ok with it. But it feels wild me to me to say that the cross-site caching wasn't worth anything. It was a super excellent path to fast loading, was enormously enormously helpful, especially for the age, when very few people had reliably low latency high bandwidth broadband.
That doesn’t mean they don’t get evicted though, right? I imagine a browser has a maximum cache size and FIFOs the cache if it is filled.
The vibe isn't the issue, the implemented solution just didn't work.
It won't work today, but was this really so improbable in the past? There was a time when jQuery was so ubiquitous to be almost a "de-facto standard" at it also had a "canonical url" to load from (per version at least). Why would it have been so improbable that a user visited two or more sites that used the same jQuery version and also included it from the canonical url?
I can only imagine "naturally" producing this scenario by browsing HN in 2010 and clicking every link on the front-page and hoping at least 2 were indie blogs or startups that don't take security seriously, and even then if they're not consecutive, the website between them would have likely evicted the cache.
Supply chain attacks will cause catastrophic damages and massive internet problems one day, as they have. DDoS/outages to the cdn js/resource suppliers and websites come to a standstill. why not host your own .js files? lazy upkeep?
I don't have a solutions for it all, but better to think about solutions now than when solutions are needed because a massive hack happened at some point.
Why not? This is the simplest and most robust technique.
Not everything needs to be part of some nerdtastic dependency resolution architecture. The web is messy. Grab the files you need, keep them safe and move on. There are so many other problems to solve.
So an inferior version control system that works at odds with the main one that you're using to manage your repo (probably Git) and that works against anyone who's interested in what the version control system is supposed to be for?
Just commit the code to your repo. Orthogonal/overlay SCMs like NPM were a mistake—promulgated by people with serious misapprehensions not unlike those that are the target of the article linked here, i.e. those who are (still) insistent on using JS CDNs for <reasons>—ones they can't explain, but that they're sure makes it a good idea. I mean, doing it this way has got to be good for something, otherwise there wouldn't be so many people doing it this way, right?
Still, I see the allure of having someone else cdn for you. They have a significantly better serving system than many of us, and it's traffic we don't have to serve.
A naive usage of cdn will have both information-leak problems and expose a security issue, as described in the article. But.
You can basically eliminate the information-leak problem by using a restrictive referrerPolicy (which can be set on fetch or a <script> tag). This will quite effectively blind the cdn to where specifically the traffic is coming from.
You can eliminate the security risk by specifying a subresource-intergrity for your assets. This will prevent the CDN from modifying the file from what you expect.
Call me old-fashioned, but if JavaScript is a large portion of your server's HTTP traffic, you're doing something wrong. (Unless the JS is only comparatively big because your website is just text, in which case, who cares? You can serve 100 requests per second of static text with a Raspberry Pi and a 50mbit connection. And with any more traffic than that, you'll want a CDN of your own anyways.)
One security flaw and thousands are affected.
Maybe back to on prem would be better.
You can consume a cloud service from your backend, thus insulating it from your user’s browser.
Sometimes the cost of a 3rd party service is much much cheaper vs on prem (the cost of hardware, yearly maintenance, etc)
On prem isn’t strictly better security wise either. On prem software can have vulnerabilities baked in to the product which could be exploited much more quietly, since the blast radius is a single customer
You don't have any clue about the sizes of the cloud customers' architectures. Like a Kubernetes Cluster of size far, far beyond its advertised 5000 nodes limit.
Maybe if you have a Wordpress site or a tiny internal-only corp React website then it might be feasible to go back on-prem. But the world is already run by a few cloud providers, whether you like it or not.