# Public CDNs Can Create Security, Privacy, and Stability Risks

DevFeed: [Public CDNs Can Create Security, Privacy, and Stability Risks](<https://devfeed.tech/articles/public-cdns-are-useless-and-dangerous-19093.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/public-cdn-risks/>)

Author: HTTP Toolkit; Tim Perry

Published: 2021-07-19T14:15:00Z

Content type: opinion

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [cdnjs](<https://devfeed.tech/topics/cdnjs.md>), [Security & Privacy](<https://devfeed.tech/topics/security-privacy.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [modern web development](<https://devfeed.tech/topics/modern-web-development.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [jQuery](<https://devfeed.tech/topics/jquery.md>)

Tags: [browsers](<https://devfeed.tech/tags/browsers.md>), [caching](<https://devfeed.tech/tags/caching.md>), [cdn](<https://devfeed.tech/tags/cdn.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [performance](<https://devfeed.tech/tags/performance.md>), [reference](<https://devfeed.tech/tags/reference.md>), [security](<https://devfeed.tech/tags/security.md>), [security-privacy](<https://devfeed.tech/tags/security-privacy.md>)

## AI overview

This article argues that using public CDNs for common scripts and styles can introduce security, privacy, and stability risks while providing limited modern benefits. It recommends self-hosting content and dependencies, with a private caching CDN placed in front of the application for performance.

## Source excerpt

Once upon a time, loading common scripts & styles from a public CDN like cdnjs or Google's Hosted Libraries was a 'best practice' - a great way to instantly speed up your page loads, optimize caching, and reduce costs. Nowadays, it's become a recipe for security, privacy & stability problems, with near-zero benefit. Just last week, a security researcher showed how this could go horribly wrong. There are ways to mitigate those risks, but in practice the best solution is to avoid them entirely: self-host your content and dependencies, and then use your own caching CDN directly in front of your application instead for performance. I'll explain what that means in a second. First though, why was this a good idea, and how has it now become such a mess? Why was this a good idea? The main benefit that public CDNs of popular libraries offered was shared caching. If you used a popular version of jQuery then you could reference it from a public CDN URL, and if a user had recently visited another site that used the same version of jQuery from the same CDN then it would load instantly, straight from their cache. In effect, sites could share resources (almost always JavaScript) between one another to improve caching, reduce load times, and save bandwidth for sites and visitors. Even in the uncached case, this still offered benefits. Browsers limit the number of simultaneous open connections by domain, which limits the performance of parallel resource downloads. By using a separate domain for some resources, resource loading could be spread across more connections, improving load times for visitors. Lastly, the main site's cookies aren't sent in requests to 3rd party domains. If you have large cookies stored for your domain, this creates a lot of unnecessary data sent in every request to your domain, again unnecessarily increasing bandwidth usage and load times (honestly I'm not sure if this overhead really had a practical impact, but it was certainly widely documented as an impor