By James Allen

The Importance of Client-Side JavaScript Security

By James Allen

This article was provided by JScrambler. Thank you for supporting the partners who make SitePoint possible.

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.

JavaScript is Everywhere

JavaScript is an incredibly powerful language, but it also has one defining flaw in regards to security: It is an interpreted language. Instead of being compiled to machine code before distribution, JavaScript code is executed at runtime. This, of course, also means that, by default, virtually everyone who downloads JavaScript-based software will have full access to the code that drives it.

The fact that JavaScript is now even capable of operating outside the bounds of the web browser makes security an even more important topic, if only as a result of the sheer volume of uncompiled code out there. In a browser, JavaScript is usually “sandboxed”, meaning that, unless there’s some flaw, it’s relatively safe for your system.

Now, though, there are plenty of frameworks with standardized APIs out there like PhoneGap, Cordova, Node Webkit, and so on, that allow JavaScript to interact with the native system APIs. These offer a lot of flexibility and power to JavaScript application developers.

For example, you can code HTML5 and JavaScript desktop software that is able to read and write files to your hard drive or otherwise use your native system functionality, like allowing access to your camera, phone information, wifi, bluetooth, GPS, and so on.

When you add all this together, it makes for a pretty big source code playground for would-be hackers to play around in.


What is the Role of JavaScript Obfuscation?

When it comes to client-side JavaScript security, there is nothing developers can do to ensure 100% protection. With that said, however, here’s where JavaScript obfuscation comes into play.

Obfuscation is the process of methodically going through your code, transforming and rearranging it, all with the goal of making it virtually impossible to read and understand it with the naked eye but keeping its functionality. (Note: minification is different from obfuscation, you can easily retrieve the original code from minified code.)

Although it does have its limitations, short of locking all your code on a server, obfuscation is the best option that developers have to protect their JavaScript code. But not all obfuscation is actually protecting your code.

Choosing the Right JavaScript Obfuscator and Beyond

With the dozens of obfuscation programs to choose from, how do you choose one that is right for you? Here are some things to consider when choosing.

Download source. Possibly the most important consideration is the source you’re downloading the software from. And this particular piece of advice should apply to pretty much anything that you download from the Web. Always check the reputation of where you’re downloading from.

In “Why A Free Obfuscator is Not Always Free,”Peter Gramantik describes an experience he had with a “free” JavaScript obfuscator. He describes how the code was obfuscated, but the program also inserted its own malicious code into the mix.

If he hadn’t de-obfuscated the code to see what was really going on, he never would’ve noticed it. The moral of the story: Always be skeptical about where you download your software from.

Compatibility. The next most important feature to look for is compatibility. Make sure that whichever program you choose is compatible with any libraries you may be using. If you don’t, the code it outputs may not work anymore, and you might spend more time than you’d like tracking down and fixing errors.

Additional features and resilience. Other things to keep an eye out for are additional features and the resilience of the protection that may be offered by the program you choose. Some services come in a professional, integrated package — and some even offer some extra features that go beyond obfuscation! These features allow you to make sure the protection you’re applying is not easily reversed in minutes and can even help you enforce licensing on your apps. For example, JavaScript Protection company, JScrambler offers:

  • JavaScript obfuscation
  • performance optimization through minification
  • dead code insertion
  • function outlining
  • browser and domain locking
  • expiration dates on code functionality
  • thwarting JavaScript dynamic analysis with anti-debugging and anti-tampering techniques
  • compatibility and compliance with tons of JavaScript libraries

This rise in the use of JavaScript brings with it great promise, but the combination of its interpreted nature and it’s increased use also opens the doors to more risk. But it doesn’t have to be something scary, as there’s much you can do to reduce the risks for your business.

If you have sensitive client-side JavaScript code, and if you want to keep that code from being tampered with, it’s worth investing in the best JavaScript protection to provide that extra layer of security you need. If you’d like to check out some of what JScrambler offers, check out to sign up for a free trial!

  • This… just makes it difficult for an attacker to find an attack vector: it doesn’t solve ANYTHING AT ALL security-wise.

    As they say “security through obscurity” is a quite useless practice that just helps making your own toolchain more complex (at your own expense, both in toolchain and maintainability).

    My suggestion is to simply not use obfuscators, at all.

    • Schipperz

      Fully agree, its pointless to do so. Security of your data belongs on the server not within the frontend. The frontend is for data display + data editing.

      The server is responsible for access management of the data and data validation.

      • There is an good idea how U can make $95 /h… After being without work for six months , I started making cash over this site and today I possibly could not be happier. 3 months have passed since being on my new job and my income is around five thousand dollars/monthly If this interests you: 1)go to the website in description

      • Charlie Silva

        There are cases where you have to put logic within the frontend, take browser games or google maps for that matter! :)

        • Schipperz

          Still disagree currently working on a project involving games and in that project one of the game developers stores the score in the frontend as well. This has resulted in the most easy way to gain the system since they can without any problem change the local storage values. Which without any server checks are pushed to their server and then to ours and stored in the high scores table.

          This highlights a perfect example where relying on the frontend for any sort of data storage without validating it is pointless.

          Never ever in my book should anybody mix the concerns for data security and validity with a place that has no such securities.

          Your server is responsible for it not your frontend.

          • Paulo Silva

            @schipperz:disqus what about your game logics? Is it an HTML5 game?
            I am pretty confident that security and protection are two different things.

            I DO NOT and NEVER WILL advice security through obscurity, but what about intellectual property?
            How many time and money did you invest to develop your game? Let’s say a considerable amount.

            What barriers will I find to download your HTML5 game source code, remove the server connectivity logic, add mine and deploy it on my own server? Probably you will agree: a bit smaller than you.

            How late you will be knowledgeable about copycats?
            Isn’t it fair to do whatever you can to protect your assets and most of all, your business?

            We are not talking about a “traditional” security and Jscrambler is not the right tool for, let’s say, SQL Injection. We all know how to solve this “little” old issue: developers education.

    • Charlie Silva

      I disagree, if it makes it more difficult for an attacker to find an attack vector it is useful for making your application safer. Not least, it acts as factor of demotivation. If you would follow your logic on other things, we wouldn’t be putting locks on our doors, just because they can be broken…

      • If you would follow your logic on other things, we wouldn’t be putting locks on our doors, just because they can be broken…

        The fact that you made something accessible means that any kind of business interest will lead people to go through that lock, at least on the internet.

        The fundamentally broken part in this article is assuming that there can be client-side breakable business logic, which is a huge design fallacy.

        You don’t put the money of your clients under their mattress, private house (client side), you put it in a bank and throw guards in it (server-side).

        User-space memory is pretty much owned by the user: regardless what technique you use for making it unreadable, as long as it is readable (obfuscation just scrambles it, it’s not crypto) the client can attempt things.

  • Joseph Pulse

    That happens only with some javascript obfuscators…I’ve been using JScrambler with my project, there’s no blocking whatsoever. I’m guessing they managed to avoid that.

    • Oh thanks for letting me know about that one, I’ll check it out to see how it goes. :)

Get the latest in JavaScript, once a week, for free.