This post advocates minimizing dependencies in web pages that you do not directly control. It conflates dependencies during build time and dependencies in the browser. I maintain that they are essentially the same thing, that both have the same potential problems, and that the solution is the snappy new acronym HtDTY - Host the Damn Thing Yourself.
Build Time Dependencies
With increasing frequency the supply lines for software development are under attackWidespread Supply Chain Compromise Impacting npm Ecosystem
Supply-chain attack analysis: Ultralytics
Two recent examples I found with 10 seconds of Googling. All the package managers and libraries that seem to be essential for modern web development provide a rich surface for attackers to sneak code into your software to exploit you and your users, stealing credit card information or CPU cycles.
I am not singling out a particular package manager or language here. The problem is universal, if you import a package, you are trusting the publisher (and the publishers of all the packages it relies on, all the way down) with the integrity of your software in a distressingly intimate way.
Be honest, your bespoke web app effectively has contributions from hundreds of people, most of whom you do not know. We like to think our software as beautiful oil paintings but it is probably more correct to think of them as messy collages consisting mainly of pictures clipped from magazines.
In most cases you have no directly link to the publisher and no recourse if the package turns out to be malicious. The buck stops with you, and by buck I mean legal liability. You can’t say to your users “Sorry your bank account got hacked while using our site, a package we use was corrupted by bad people - we are victims here as well.”
And just because a package is fine today doesn't mean it will remain so. Developers get hacked all the time and popular projects have to implement procedures to ensure all changes are from trusted people. But it only takes a single slip-up for an attacker to introduce malicious code.
And it doesn’t even have to be malicious. Projects get abandoned all the time as unpaid developers move on to something else. If you try to rebuild a project today in five years time you might find that some of the dependencies no longer exist. One of the most important dependencies is the package manager repo itself - maybe it will no longer be operational.
What to do?
You package manager probably supports pinningif it doesn’t, find a better package manager. Version pinning, while useful for controlling upgrades, does little to prevent malicious packages from being included. If you pin UsefulPackage to version 2.3, nothing stops the publisher from publishing a malicious package with the same version number to be included in your build at a later date.
Including a hash in the pin is slightly better. This protects against somebody modifying the contents of the package in the case the the package manager repo itself or your connection gets hacked.
But nothing protects against the package manager repo itself disappearing after a few years. This is why I advocate HtDTY. Either include the packages directly in you source control system (the easy option) or set up a local repository to serve the exact packages you need (annoying but “cleaner”, especially for big teams).
Browser Dependencies
There is another place where your content gets potentially linked with that of other publishers that might not share your goals - the browser. When a browser renders a page it pulls in the resources it needs - resources that might be out of your control.
It is common for resources like Javascript libraries and fonts to be served via CDNs. The argument for doing this is that the browser can cache these thing across sites, speeding up browsing for your users. This is effectively another supply chain that can be attacked, one that is even more insidious since you do not control the network between your users and the CDN.
At the very least, Subresource Integrity should be used to ensure nothing is monkeying with the content.
But I argue that the supposed benefits of CDNs for Javascript and fonts are largely illusionary anyway. In theory, each user would download $LargeJSLibrary once and cache it, allowing sites A, B, and C to load quicker. In reality, site A uses $LargeJSLibrary.ver3.2, site B uses $LargeJSLibrary.ver3.2.1, and C uses $LargeJSLibrary.ver1 from 4 years making the cache useless.
In return for not providing much benefit, the CDN networks can build up a picture of your user’s browsing habits for advertisers to fold into the existing sack of data they hold for everyoneThis is a personal bugbear of mine and I could go on for paragraphs about sites trading away their reader's privacy for a few cents of advertising money. Suffice to say, I would avoid CDNs for this reason alone even if I thought that CDNs were a sound technical idea.
My advice is to avoid CDNs and just HtDTY by including the resource as part of your build process.
The situation might be a little different with large resources like images and video, but even here think very carefully before relying on third parties that can change their services without recourse. Thousands of web forums and blogs find this out each time a web services like Dropbox or OneDrive decide (quite reasonably from their point of view) to disallow image embedding.
If your resources are large enough to cause a problem if you Host the Damn Things Yourself then consider finding ways to cut back on their size. Or follow my related advice - HtDToaSYHaBRW IMCYMbT(P)WDWYD : Host the Damn Thing on a Service You Have A Business Relationship With, It May Cost You Money But They (Probably) Won’t Dick With Your Data.
HtDTY has additional benefits. If all your resources come from the same server then the browser does not have to make additional DNS lookups and connections. This can be significant on poor connections, like we all experience from time-to-time on cell phones.
It's not like the bad old days where multiple requests to the same domain were expensive for both the client and server. With modern protocols like HTTP/2, additional requests are very efficient, quite possibly not even incurring a round-trip time cost.
Conclusion
Of course, it is impossible to completely eliminate dependencies. We are obliged to trust the browser itself, the user's OS, and the computer hardware itself - none of which are immune to supply chain attacks. But as software developers, we can make sure that our part of the line between the users and greedy evil-doers is as secure as we can make it.
Be careful out there.