The Importance of Client-Side JavaScript Security

It seems like no matter where you look these days, you're bound to see something that has been created, at least in part, using JavaScript.

One reason for this is that JavaScript is so easy to learn and use. Another reason has to do with the wide availability of easy-to-incorporate, open-source libraries like jQuery, React.js, Backbone.js, Angular.js, and Ember.js.

When added together, this makes for a huge boost in development potential. People who have great ideas for applications don't necessarily need to be developers or hire developers in order to make those ideas a reality.

Of course, this ease of development also opens up the increased risk of security vulnerabilities, too, since these libraries can be included and used, all without having to know what's really going on under the hood.

JavaScript Security

There are basically two lines of thinking when it comes to JavaScript security: one being the issue of protecting your code against being hacked, and the other being protection from a proprietary standpoint — preventing your code from being tampered with or stolen.

Server-side hosting. Traditionally, code protection meant storing as much code on the server as possible. This kept your code safe from prying eyes, and it also allowed the server to do the heavy lifting, performance-wise.

This still holds true today, but it's far from a one-size-fits-all solution. Storing your code on the server certainly does offer the best protection, but it also has some disadvantages, too.

One downfall is that it means that you're forcing an internet connection. This isn't always a problem, but it's not feasible if you're developing an application you want to work offline.

Another consideration is performance. Server calls take time. This isn't a huge issue for simple apps, but it may be one for high-performance apps like games, where excessive latency can ruin the user experience.

Why encryption won't work. An inevitable question that many ask is, "Why can't I just encrypt my file?" This is a great thought. Really. The problem is that it doesn't quite work that way. You can encrypt the files, but then they won't be of any use to the browser. You'll need to decrypt them to make them readable to the browser, putting you back to square one.

Continue reading %The Importance of Client-Side JavaScript Security%

by James Allen via SitePoint