35

I know its impossible for 100% protection, but something high or that works for majority of the users.

For instance, I encountered a site where viewing the current page's source returned nothing.

In another case, accessing or trying to download the .js files itself from browser

http://gget.com/somesecret.js,

would redirect you and stuff.

If you obfuscate your code, will it be very very difficult to decode it? if so that is also another good solution (what software is recommended) ?

Yi Jiang
  • 49,435
  • 16
  • 136
  • 136
wghwh
  • 435
  • 1
  • 6
  • 6
  • 2
    I don't know if obfuscated code is easily decodable, but look at google javascript, and try to "steal" it :) – Aif Nov 02 '09 at 08:45
  • 6
    As you said, there's no 100% protection. I'd say anybody who is sophisticated enough to do anything worthwhile with "stolen" JS code is also sophisticated enough to circumvent any hand-waving you might employ to hide your script. I.e., it's a pretty pointless undertaking IMHO. – deceze Nov 02 '09 at 08:48
  • 1
    Another solution, very highly abstracted, is to couple your javascript tightly with your server side code so that even if someone did steal your JS it would be too much work for them to use it themselves. – Jeremy Powell Nov 02 '09 at 17:15
  • 1
    If you have a true 'secret sauce' to protect, then wrap it up as a server function which is called via ajax. Slower, securer. – James Westgate Jul 20 '12 at 08:09
  • 1
    What if I add code that checks the domain name, then obfuscate it? – Lev Feb 10 '18 at 10:18

10 Answers10

46

It's simply not possible.

For a visitor's browser to be able to execute the script, they have to be able to download it. Not matter what trickery you try to pull with JS, server permissions etc., at the end of the day they can always just wget http://example.com/yourcoolscript.js. And even if they can't (e.g. you require "secret" headers for that request) that would likely inhibit the behaviour of most browsers, while not stopping a determined person from looking anyway.

Fundamentally, because JS is executed client-side, the client must have access to the "original" JS file.

One minor thing you can do is obfuscation, which can help a little bit. But since JS is interpreted, it's also its own deobfuscator - see one of my earlier answers for an example.

Basically - "if you build it, they will look". :-)

Community
  • 1
  • 1
Andrzej Doyle
  • 102,507
  • 33
  • 189
  • 228
  • 6
    It's possible to put some TCP/IP listener between the browser and the server with which you can see the HTML and JavaScript that's communicated between them. So "secret headers" aren't really any good. – Jesper Nov 02 '09 at 08:56
  • @Jesper such listeners already exist and are easy to use. Set up a caching web proxy (such as squid) or an http traffic sniffer like fiddler and you're good to go. – Wedge Nov 02 '09 at 09:01
  • Jesper - I agree, that's broadly what I meant by "not stopping a determined person from looking". A browser has to be able to see the file in normal operation, and anyone can behave sufficiently like a browser to get the file themselves. – Andrzej Doyle Aug 19 '11 at 09:16
  • check this website out http://samy.pl/ – shunz19 Apr 19 '20 at 05:36
35

There are two kinds of user: There is the large group who couldn't care less. No need to protect against them.

Then, there is the group who really wants to see how you did it. There is no way to protect against them. They have all the tools and the knowledge to circumvent any protection you could come up with. You could use obfuscation but that's going to cost you money and time, so in the end, you can only lose.

Create a great product plus offer good support and people will be willing to pay for it. Castle building didn't work well in the past (lot of effort and it took just a couple of stones to tear them down) and it surely doesn't work today.

If you're afraid that your ideas are going to be stolen, then look for a new job, because they will be and there's nothing you can do.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
20

You could obfuscate your Javascript. There are a lot of tools to do that in the wild, e.g. http://www.javascriptobfuscator.com/. However it does not prevent anyone to see the code, but makes it harder to read.

spa
  • 5,059
  • 1
  • 35
  • 59
  • How will it protect the code? Deobfuscation is as easy as obfuscation. [Deobfuscation link](https://www.javascriptdeobfuscator.com/) – Saransh Apr 05 '18 at 05:54
  • 3
    It will not. As said it just makes it harder to read. – spa Apr 05 '18 at 09:40
  • 3
    I would say obfuscation makes code harder to understand, not to read. Those tools will change identifier names to some randomly generated code. Deobfuscation tools can only beautify the code. It can never find the actual purpose or name of an identifier. So it makes no sense to future readers. – Bertram Gilfoyle Sep 10 '18 at 13:59
19

If you have big secrets, keep them on the server.

Then bundle all your JS files in one file, that you obfuscate.
This should prevent many people to go further, and as well reduce size and http calls.
But this won't stop the real bad guy if any.

We're building a JS heavy app and cured this paranoia long time ago.
If fact, we did the opposite.

As nothing can be protected, why not open source useful parts and get feedback from other people?
Try it, you won't be disappointed.

Mic
  • 24,812
  • 9
  • 57
  • 70
17

One idea is to use websockets to serve javascript files to the browser through a socket.listener and running with eval. That way, it's very very very difficult for anyone to see the actual "source", since the connection of the socket has been already closed.

There is another amazing tactic which can be seen on the homepage of http://samy.pl, which uses spaces (\u0020) and tabs (\u0009) as a byte cipher to hide JS code!

If you view the source, you can only see 1 line of actual JS code: http://pastebin.com/e0pqJ8sB See for yourself if you can figure out how it works (no spoilers!)

As far as obfuscators go, see http://utf-8.jp/public/jjencode.html (and/or another version)

This free obfuscator runs client-side, and produces gibberish that unminify.com and jsbeautifier can't even decode:

$=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++$,$$__:({}+"")[$],$$_:++$,$$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($.$=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"\""+$.$_$_+(![]+"")[$._$_]+$.$$$_+"\\"+$.__$+$.$$_+$._$_+$.__+"(\\\"\\"+$.__$+$.__$+$.___+$.$$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$._$+",\\"+$.$__+$.___+"\\"+$.__$+$.__$+$._$_+$.$_$_+"\\"+$.__$+$.$$_+$.$$_+$.$_$_+"\\"+$.__$+$._$_+$._$$+$.$$__+"\\"+$.__$+$.$$_+$._$_+"\\"+$.__$+$.$_$+$.__$+"\\"+$.__$+$.$$_+$.___+$.__+"\\\"\\"+$.$__+$.___+")"+"\"")())();

Original code:

alert("Hello, JavaScript")

Output from both beautifier websites:

$ = ~[];
$ = {
    ___: ++$,
    $$$$: (![] + "")[$],
    __$: ++$,
    $_$_: (![] + "")[$],
    _$_: ++$,
    $_$$: ({} + "")[$],
    $$_$: ($[$] + "")[$],
    _$$: ++$,
    $$$_: (!"" + "")[$],
    $__: ++$,
    $_$: ++$,
    $$__: ({} + "")[$],
    $$_: ++$,
    $$$: ++$,
    $___: ++$,
    $__$: ++$
};
$.$_ = ($.$_ = $ + "")[$.$_$] + ($._$ = $.$_[$.__$]) + ($.$$ = ($.$ + "")[$.__$]) + ((!$) + "")[$._$$] + ($.__ = $.$_[$.$$_]) + ($.$ = (!"" + "")[$.__$]) + ($._ = (!"" + "")[$._$_]) + $.$_[$.$_$] + $.__ + $._$ + $.$;
$.$$ = $.$ + (!"" + "")[$._$$] + $.__ + $._ + $.$ + $.$$;
$.$ = ($.___)[$.$_][$.$_];
$.$($.$($.$$ + "\"" + $.$_$_ + (![] + "")[$._$_] + $.$$$_ + "\\" + $.__$ + $.$$_ + $._$_ + $.__ + "(\\\"\\" + $.__$ + $.__$ + $.___ + $.$$$_ + (![] + "")[$._$_] + (![] + "")[$._$_] + $._$ + ",\\" + $.$__ + $.___ + "\\" + $.__$ + $.__$ + $._$_ + $.$_$_ + "\\" + $.__$ + $.$$_ + $.$$_ + $.$_$_ + "\\" + $.__$ + $._$_ + $._$$ + $.$$__ + "\\" + $.__$ + $.$$_ + $._$_ + "\\" + $.__$ + $.$_$ + $.__$ + "\\" + $.__$ + $.$$_ + $.___ + $.__ + "\\\"\\" + $.$__ + $.___ + ")" + "\"")())();

Hope this enlightens those in need!

Marcelo Rodovalho
  • 880
  • 1
  • 15
  • 26
  • 1
    Can't I can just place a breakpoint near the eval, check the value of the variable it's trying to proccess and acquire the Javascript? I think it's rather trivial... – David Mar 18 '14 at 14:04
  • 1
    i would just patch up eval to output the code before evaluation – Guillaume86 May 15 '14 at 10:21
  • Yeah, but you can use a random code obfuscator to generate the output source. Then, everytime the same request is did, a differente code is outputed. Some obfuscators, you can use a decrypt key to use in the eval function. Is not impossible. But very hard. – Marcelo Rodovalho Jan 05 '15 at 18:03
  • 3
    @MarceloRodovalho I saved entire page with ctrl+s ! – Mironline Feb 10 '16 at 21:39
  • 1
    @Mironline The dude in the entire page, use a combination of "space" and "tab" to hide their code, (space = 0, tab = 1). After, he decode with ".source.replace(/.{7}/g,function(w){document.write(String.fromCharCode(parseInt(w.replace(/ /g,'0').replace(/ /g,'1'),2)))});" to render the "real" page. – Marcelo Rodovalho Feb 11 '16 at 16:59
  • 1
    @Mironline - Yes I tried this with ctrl+s. It seems to have saved the page of "samypl" and all the source js and css, although a little more decryption is needed. For trying to protect your code this seems like an amazing method, but it's not full proof for those looking to explore this. – Michael d May 29 '17 at 22:44
6

Don't waste your time. If a browser can download it to run it (and it can, otherwise the code is useless), a program can be written to download it and save it.

Time and time again, we've seen that technological methods to protect things like this don't work.

Do you really think that your JS code is so precious that it needs that sort of protection? Once you get it working, by all means run it through a minifier if only to speed up the download process. But as to protecting it, I would concentrate on what you do best (which I'm assuming is coding it).

If you really need to protect the code from being viewed, don't do it in client side JS. Put it on the server and just use JS to communicate with that.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
5

Especially in modern browsers, it's a complete waste of time.

I can use Firebug to see somesecret.js... as for the other I'm better if you'd scrolled down you'd see the source.

You can minify or obfuscate your code, which will make it difficult to alter (but not to take an exact copy). Minification is recommended as it will result in your page loading slightly faster.

Greg
  • 316,276
  • 54
  • 369
  • 333
  • how to minify and obfuscate my code? is there a software i can use? is a web based ones secure ? im aware people can use firebug and view everything.... but i want to make this difficult. it wont be perfect but it wil lbe good enough if i can keep out majority of people. – wghwh Nov 02 '09 at 08:48
  • have a look at YUI Compressor, for example: http://developer.yahoo.com/yui/compressor/ – Jesper Nov 02 '09 at 08:57
2

Well, if you own the server, you can deny access from referers other than your own hostname. On Apache, you can do that through .htaccess.

You can also use Dean Edwards' packer to pack your production Javascript codes.

But take note that with Firebug or other debugging tools, most people are still able to see your code through the DOM tab/inspector.

mauris
  • 42,982
  • 15
  • 99
  • 131
0

If someone does steel your code you can sue them. Your code is copyright protected. You are like the author of a novel. If anyone stole your app or any part of your code they would be guilty of plagiarism.

gloo
  • 2,490
  • 3
  • 22
  • 38
0

One thing you CAN do is to circumvent javascript altogether -- write the client-side logic in an equally or more competent language (for which you can find a javascript compiler) and compile it to javascript in the end. (This probably obfuscates the code too well)

L__
  • 866
  • 1
  • 9
  • 15