Your Website Could Break at Any Moment

I think we’re at the point where including jQuery, Modernizr, and other scripts is beyond common practice and to the point where it’s about as standard as hosting your own CSS (lame example, I know, but the point stands). We’ve gotten to this point because many external front-end dependencies are deemed to be totally reliable and often times actually a better option than hosting your own copy. The benefits of using jQuery from Google or jQuery’s CDN are undeniable but with the convenience of reliability, stability, and instant updates comes the possibility of security breaches, broken links, and the general possibility of ending up with an infected and or totally broken website.

Why do we do it?

Referencing Google’s copy of jQuery or Modernizr or HTML5 Shiv or whatever else seems innocuous enough and I’m not about to argue that we should stop doing it. We rely on these external hosts for critical parts of our site infrastructure because we trust them, they are secure (right now and relatively) and it’s damn easy! No need to host your own libraries, keep them up to date, or optimize them for fast download. Speed, as I just mentioned, is another factor. This is especially critical when it comes to JavaScript as the moment your browser gets to a line that references some JavaScript the page will cease to load until it has finished. Outsourcing your JS dependencies has two speed benefits – it allows you to rely on someone else’s super fast CDN and allows you to reference another host. Since browsers can only download so many files at once per host, having multiple hosts to download from will speed up your site. Let’s say you only used your own hostname and you have 8 files (let’s say 2 font, 2 stylesheet, 2 JavaScript, and 2 images) and let’s just say you use a browser that limits you to 4 files per host at a time. What’s going to happen is the browser will be downloading half of your files and waiting until those 4 download before it downloads the others. Like it or not (I’m in the “not” camp), sites these days reference at least 10’s of external files at a time and often end up using megabytes worth of bandwidth for them all. If you’re limites to a single hostname that’s a killer. But because we get to rely on external hosts we can cut that down. By using an external host you free up some connections. Now you can download 4 files from your own server, 4 from another host, and so on. So yeah, there are a lot of great reasons to use external hosts for your projects but one day it can become a killer. So now that we’ve clearly established that relying on other sites for your site’s JavaScript and other dependencies is awesome, let’s talk about what can go wrong.

What could go wrong?

With great power comes great responsibility and that reponsibility is for the safety and security of your users, their data, and hell, whatever private information you’ve got hosted too! When you rely on an external host that you don’t control to serve up your web assets you’re opening yourself up to attacks, dependency issues, and speed issues. Basically every benefit these services provide but in reverse.

Security

So you’re happily going along writing jQuery plugins up a storm, hosting the plugins locally and pulling in jQuery from the official jQuery CDN. No problem, right? But what happens if one day the jQuery servers get attacked? We’re talking about an incredibly popular JavaScript library that you’re serving to your users. If someone were to get into their servers and mess with the CDN copies of jQuery they can then XSS you to hell, get into your server, access your user’s browsers and any information they were to give you. I’m not aware of jQuery ever being hacked but there was once a fake jQuery site serving up malware that got to be a pretty big problem for a week or so in the summer of 2012. Is it likely? No, but no one is safe. Rubygems.org was just recently hacked. What happened to them is an example of the same type of problem. People are pulling in dependencies managed by a central source. Once that source is compromised everyone who’s used that source is also possibly compromised.

Now, in all honesty, I think jQuery.com is probably more secure than sites managed by mere mortals like you and I but the point here is to be aware of what you’re getting yourself into.

Speed

Servers go down. A lot, actually. Especially in these times of the cloud. GitHub.com, another popular source of hosted files (for some reason) has gone down quite a lot in the past year. GitHub is hosted on Amazon’s EC2 infrastructure which doesn’t have the best track record when it comes to uptime. When EC2 goes down it tends to take the entire web with it (at least as of this writing). Google, another popular source of hosted libraries, isn’t immune to downtime. They may be the almighty Google but you’re still farming out your uptime to someone else. I actually think my Linode has had better uptime than both EC2 and Google over the past 2 years. In 2 years with Linode I’ve had maybe 3 hours (that’s being generous) of downtime, three-quarters of which was scheduled. The minute someone else’s server goes down your site is broken. The solution to this is to have a fallback for all your important scripts. Check out HTML5 Boilerplate which uses a neat way to fall back on your own copy of any hosted JS library. My own HTML/CSS Framework, Fraction.less also uses this fallback method.

Versioning

Hosted libraries are great because upgrading is a breeze. But is it really all that hard to replace a copy of jQuery or something else on your site? Even if you have the version number in the filename as many do (like jquery-1.9.1.min.js) all you need to do is rename your previous version external-lib-x.x.x.min.whatevs.bak and then name the new version the same as the previous version if you’re too lazy to replace all the references that are hardcoded in your HTML (which is why you should leave the version number off in the first place but that’s another post).

This is not a call to action

I’m not saying we need to quit relying on external hosts. In all honesty, the chances of something bad happening with them are actually quite slim. What it really comes down to is your app/website. Are you in a position where you’re dealing with lots of sensitive information? Then don’t use an external library. But then again, how sensitive is it? Do you require security, uptime, and reliability up at the levels of Google? Then definitely host your own. But under normal circumstances, I don’t think I’d tell anyone not to use a hosted library. The point here is just to be aware of the potential problems and ask to ask yourself if you’re comfortable relying on an eternal host for your web assets. This site, and many others I run, including Write.app, all rely on Google for their copy of jQuery (with a locally hosted fallback, of course), Typekit and Google for their fonts, and Amazon for images. Okay, so I totally control Amazon so there’s no problem there, I just needed a third thing in the list. I take the security of my users very seriously but at the end of the day I still trust Google and everyone else I rely on for my assets more than I trust myself. I don’t care who you are, a single person running a web service just can’t match what Google and others can do with their armies of security experts.

So again, just so we’re clear, your website is vulnerable to attack and can spontaneously break at any moment. But that’s true of all websites. That’s the point. Keep using Google’s copy of jQuery – I doubt you’ll get burned by it – but just be aware that no one is safe from attack and the more external hosts you rely on the more points of failure you’re opening yourself up to.

Highlights, Web design, Web development

« I Took a Walk DigitalOcean, Linode, and Nginx »

Comments