Take the 2-minute tour ×

When you compile and distribute a client you are automatically protecting yourself from someone seeing and modifying your code. Can this be achieved on a Javascript client?

share|improve this question
Copying and viewing the code (the compiler's output, of course) is trivial. Understanding it may be slightly harder, but compilation alone only gets you this far. Also, the code has to be decrypted for the engine to run it. –  delnan Mar 3 '12 at 20:01
This is called security through obscurity, which isn't real security, hence no. –  Raynos Mar 3 '12 at 20:06
If you look at it, Flash is just about as powerful for web the way javascript is indefensible. But the former originated as a private standard and later was more of open standard. This is usually a pattern that single company originated standards solves such problems before they become dominant in market, and for open standards this is usually an after thought. There is nothing that stops your from creating JavaCrypt which will be all javascript but will be binary and encrypted. I guess the only thing is it is too late! –  Dipan Mehta Mar 4 '12 at 5:12
Geez, can't this be closed as: Duplicate, Not Productive, Flamebait, Do a Google search 1st, etc, etc, etc? –  Paul Mar 4 '12 at 14:41
@Paul, yes. You do this by clicking the "close" link under the question. Also, for Google searches show the actual search finding the answer you think of. –  user1249 Mar 4 '12 at 16:16
add comment

5 Answers

Regarding client-side javascript code, which is what we usually see on the web, is unusable when put through an encryption scheme as the web browser needs to read the code so it can be interpreted by the browser. Usable javascript code is always trivial to view and get a copy of.

You could obfuscate the code, making it harder to understand, with a minifier such as the yui-compressor. Though its purpose is to compress the code so that the cost of bandwidth can be cut down or if you are concerned for having it load fast enough for your users.

Does this mean it is easy to "copy"? It depends on what your javascript code does. Most of the javascript code that is difficult to reproduce is tied to something it expects from a web server such as JSON/XML/HTML data. Web applications are difficult to copy because they depend on code-behind from different data sources.

By the way, don't worry, others will try to steal your site...

Anecdotally I used to work at a e-commerce store that has a very nifty designer web application. The customers can design the product the way they want it and the controls on the website rely heavily on javascript. A lot of people have tried to copy the site and seemingly fail for which we only could secretly scoff about (and feel a teeny bit proud about ourselves):

  • We found through a Google Alert that a shady chinese site completely ripped the site for their own (not even replacing the logo). Apparently they tried to set up their own store. The problem was that they didn't have the graphical assets that our backend provided. Thus they clearly haven't had any use other than to show off on "hey, look what we can do".

  • For years we've seen several freelancer.com ads where we were referred to which didn't seem to pan out, probably due to the ridiculously proposed budgets, short time schedules and poor description of what they want to do with it. For some reason the people who put these ads up have no idea how incredibly complex the business behind the website really is.

  • Sometimes people are really lazy: One time we've got a call from a company who wanted to know who designed our website. Apparently some design agency was using us as reference and the problem is that we did it all in-house.

This shows that even if you have a javascript web app, it is still difficult to copy it and make a business out of it because you have everything else under the hood to worry about. In our case we had most of the product structure and graphical assets done in the back end, not to mention the production pipeline to produce the actual products that also needs to be in place. So it's all not just web development.

share|improve this answer
add comment

"Protected"? No. "Inconvenient"? Yes. (Just as with binary.)

At a certain level, no popular operating systems (yet) can prevent a sufficiently motivated actor from recovering the in-memory representation of your program and reverse-engineering it. So the "protection" is only relative to the value of your code to another.

If you accept that it is a matter of degrees, then the question becomes "Is it possible to make JavaScript quite inconvenient to understand?"

It is:

  • Trivial to make JavaScript somewhat difficult to undersand using a minimizer
  • Fairly easy to make JavaScript rather difficult to understand using an obfuscator
  • Theoretically possible to make JavaScript quite difficult to understand using your own obfuscation protocol (i.e., encrypted payloads, program execution based on deceptive side-effects and intentional use of language edge-cases)
share|improve this answer
add comment

No JS obfuscator is worth the money and sweat to use them.

JavaScript can always be reversed, and no matter what the obfuscator's method is, you will able to run through the obfuscated code and study it in any modern browser. Except if the obfuscator would also package code meant to make your life harder to prevent the use of debug tools, but it would just be eventually circumvented and rendered useless as well.

If you really need secrecy for your code, then don't use JavaScript and rely on other technologies. If you approach the problem the other way around, and you already built the new coolest JS-based web-app and want it to be hidden: give it up.

So, I'd say no, you can't really protect it, and don't bother spending cash on paid obfuscators (if you want to waste time, feel free to use the free ones out there, though they're barely worth your time too). Just use a good minifier / compressor / compiler to reduce the pay load. It will already make it harder to read, but not longer to run as will a lot of obfuscators. And it's still less readable to make it slightly more annoying to read and discourage some.

For good minifiers / compressors / compilers, read my answer (and the rest of the thread) to: What do you Use to Compress JavaScript Libraries?

Also, when distributing a client, you're not really protecting yourself that much either. Disassemblers exist and knowledgeable software engineers who know how to use them are legion. Don't rely on obfuscation / obscurity for security, and don't consider a client a trade secret.

If you really meant to encrypt the JavaScript code, that would imply that something needs to decrypt it before executing the code, meaning you'd need to either have a browser plugin installed on all clients or to have your page contained a JS-based decryptor, essentially giving the tool to anyone who'd like to decrypt the code. Additionally, the browser would see the decrypted version at runtime anyways.

share|improve this answer
I'd add.... Nothing you will ever do it going to be worth protecting. Just because it's hard and unique to you doesn't mean a bunch of other people have already done it. –  Paul Mar 4 '12 at 14:43
@Paul: I assume you meant "haven't already done it". Or that they might in the future anyways. True, although idealistic. It can be understandable for companies to want to protect intellectual property (by way of copyright law) and to even protect trade secrets. I'm not in favor of it (and strongly opposed to software patents and patent systems in general), and think that hiding said secrets is just slowing down the whole research evolutionary process and the commercial ecosystem, BUT I can still understand the financial reason for some, especially when it's all they have. –  haylem Mar 4 '12 at 14:48
@Paul: but that doesn't take away the fact that trying to do it for client-side JavaScript is a waste of energy, effort and brains. It's a losing battle, and not even one that's worth fighting. –  haylem Mar 4 '12 at 15:30
add comment

You can but it would be pointless. The browser has to eventually see unencrypted javascript otherwise it cant run it. It would then be trivial to find what the browser is currently running.

If you need lots of security on your client side code then your doing something wrong. You should be doing your complex logic and validating inputs on the server side.

On a side note, its also worth mentioning that its also trivial in most languages to get from compiled code to human readable code. There are techniques to make it harder but none of them is perfect.

share|improve this answer
I disagree with "If you need lots of security on your client side code then your doing something wrong". JavaScript-heavy apps are becoming more and more commonplace, and it's reasonable to not want your JS source code to be easily accessible to anybody using the app. –  nicholaides Mar 3 '12 at 23:06
@nicholaides - Am curious. Why is it reasonable to not want your code to be accessible? How useful is it to someone who doesn't have the server-side code to go with it? –  jmort253 Mar 3 '12 at 23:13
add comment

..because they can implement your app on their own server, and use your back-end resources to power their site. Many client-side apps store an appKey that gives them access to the backend. That's how the server knows it's an authorized client.

Worse, I don't want them to be able to modify my client-app, such that they can clone my site, and fool users into logging into my site, while also submitting the user's password to their own database as a harvesting mechanism.

Also, imagine I offer a free web app/service .. another site downloads the client-app, and modifies it such that they charge for access, handling billing/payment collection on their own server, but otherwise relying upon the API services on my server to provide the backend to their webApp offering (that I created).

At least with the code minified, it is unlikely that they can easily edit the client-app to charge people money, or clone my site and harvest passwords, etc.

share|improve this answer
this doesn't seem to offer anything substantial over points made and explained in 4 prior answers –  gnat May 28 at 17:16
This should be posted as a comment, not an answer. –  GrandmasterB May 28 at 17:16
add comment

Your Answer


