Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Some Flash developers are afraid of JavaScript. Their point of view:

Stealing JS source code is effortless, one would just 'view source' and copy it. Yes, you can decompile Flash bytecode, however it requires more time and knowledge. As a result, JavaScript is not suitable for commercial software development, because competitors will steal the code and put the original developer out of business.

Does obfuscating JavaScript code make sense when developing commercial web applications?

Are there any obfuscation techniques that actually work? Are large companies like Google obfuscating their web application code. For example are Gmail or Google Drive somehow protected?

share|improve this question
FYI, SWF files can trivially be decompiled with SWFScan. –  Gurzo May 13 '13 at 13:42
I've always wanted to try encrypting some JavaScript, then loading it with an Ajax loader that first loads a copy of the decryption key, then loads the (encrypted) JavaScript, decrypts it, and finally creates a <script> element containing the now-decrypted JavaScript. I haven't tried because someone who's serious could crack that scheme easily and someone who's not serious isn't worth worrying about. –  Bob Brown Nov 1 '14 at 20:41

5 Answers 5

up vote 11 down vote accepted

I think the operative word in the question is "afraid." The aversion is based on fear, not fact. The reality is, the threat model isn't particularly realistic. Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's JS stolen by a competitor and then been driven out of business because of it. I'm quite confident that it hasn't happened, and isn't likely too.

Too your second question, do companies like Google obfuscate their JavaScript? Yes, but not for security! They obfuscate to minimize the side of the code, in order to reduce the download size and minimize the page load times. (See the Google Closure Compiler.) This is not necessarily how you'd obfuscate for security because the only goal is to minimize the number of bytes that have to be delivered to the client. This is what you should be focused on with JavaScript, not worrying about whether someone will be able to read it or not.

share|improve this answer
Additionally, the amount of time it would take to unminify (so, reconstruct the original logical flow of the program and translate one-letter variables into ones with meaningful names) would probably exceed the amount of time it would take to just write the functionality from scratch. And of course there's the fact that, since it's a web application, likely at least half of the logic is server-side, so the potential thief only has half an application (and if he doesn't, why use a client-server model?). –  root Aug 13 '13 at 4:55
There's also the fact that there are plenty of applications which are entirely open-source, which don't get copied and resold verbatim for a variety of reasons. Atlassian JIRA is one such application; completely open-source, not often stolen. In large part because mainly people pay for support, something the original company will almost always do best. And also in large part because it would be both obvious and extremely illegal for someone to just copy the code. And obfuscating it further would just make it slower and more difficult to support. –  root Aug 13 '13 at 4:57
can things like 'var _=_||{}' be considered as shrink the code? –  neu-rah Nov 20 '13 at 16:43

No. Obfuscating Javascript usually makes no sense whatsoever. Always assume that any logic you place on the client side can easily be obtained by a determined enough attack no matter how you obfuscate it.

Your "important" logic should be stored server side.

share|improve this answer
All obfuscators that I have tested produce code that can easily be reverse-engineered using eg. jsbeautifier.org or iweb.dl.sourceforge.net/project/malzilla/OldFiles/…, but javascript2img.com seems to add so much "carbage" code that makes it difficult to see where is the actual app logic. The downside is that they haven't released the code so we have only authors word that it doesnt add some tracking code etc. And it has a limit of 2000 lines, I have read somewhere. –  Timo yesterday

You seem to already know that obfuscation isn't actual protection, so I'm not gonna lecture you on security by obscurity.

What makes sense is this: Put your competitive code on the server to protect it, then obfuscate client-side code as much as you want. Granted, it won't give you much security but it'll definitely deter kiddies snooping around, and it'll create an impression of stronger security as a part of security theatre. Google is doing it with GMail, Facebook is doing it.

Keeping in mind that your code will be deobfuscated, you can still obfuscate it as a part of your build process to make your clients and users happier.

There are many tools you can use to achieve that: Free Javascript Obfuscator, and JScrambler (commercial) are two tools I've used before.

Update: After a discussion on The DMZ, we've concluded that yes, Google and Facebook are doing it, but probably only for file size and performance and there's doesn't seem to be anything that suggests it's part of security theatre.

share|improve this answer

Of course this is a baseless fear.

Javascript is only one part of a larger ecosystem, much more important is brand, site usability, site integrity, responsiveness and network effects.

Yeah, javascript minimisation, optimisation is good to do, but not because of these purposes.

If a competitor steals you code, you can go legal on their tails, and kill their reputation, but are they going to be so stupid (it is in the clear on their site too)?

And this argument can be made for html and images too, you obviously need to take down your whole website because people can steal it.

Personally I only obfuscate to hide my xxxxpy code ;) and take out the comments lol.

share|improve this answer
xxxpy?​​​​​​​​​ –  Pacerier May 2 '14 at 15:47
@Pacerier xxxpy is a synonym for bad (code). –  Andrew Russell May 6 '14 at 21:46
Why xpy?​​​​​​​​​​​​​​ –  Pacerier May 7 '14 at 3:06
@Pacerier in this case, I believe "x" is synonymous to "*". –  KnightOfNi Nov 1 '14 at 22:39
@KnightOfNi, Then why ***py? What does py mean? –  Pacerier Nov 2 '14 at 19:09

It the code works, obfuscation is worthless. Take this example:
Before obfuscation:

function say(whatever){


eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]
||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(ne
w RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1 3(0){2(0)}',4,4,'whatever|function|alert|say'.sp

Now, not many people would really try to understand all of that mess, but if they want to steal it, they don't need to.

The obfuscated version can be called just like the original version: say("hi").

If you don't know how the original version is called, locate the function/event where you get an alert and check if it uses a custom function instead of alert, Then use CTRL + F to find this function.

As a last resort one would simply parse the RegEx, in my example most of the "obfuscation" is just RegEx conversions of function names to the real ones at runtime. Noticed 'whatever|function|alert|say'?

share|improve this answer
Well, no. In most cases, working code is useless if you can't look at it and use its underlying structure for your own pursuits. I think a copy/paste of your competitor's code on your website would be something of a giveaway, especially if he "hid" a variable like author somewhere in the obfuscated code. Still, that was a pretty cool example of obfuscation! –  KnightOfNi Nov 1 '14 at 22:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.