What's the best way to protect proprietary HTML/CSS/JavaScript? [duplicate]

Question

I am writing a robust, scalable, and fairly complex website engine using HTMl, CSS, and JavaScript. I don't want it to get ripped off, and I'm wondering if there's any way to protect the source from being viewed in the client.

I am particularly concerned about the JavaScript, and I'm wondering if I can protect it by hosting it in seperate files that cannot be viewed directly. I have full control of my web server, and I can alter any settings to accomodate.

Kimber

Same as many prior questions, including How to encrypt HTML, CSS and JavaScript to prevent theft, [What are some good ways to prevent people from copying my source code? ](#2563275), and What is the best way to encode/protect a javascript-code?. – Clerk

Answer 1

Do the exact opposite, release your code as opensource with an MIT/GPL license. Attach your (business) name to the code and be known as the first to create application X. Reputation gets you much farther then futile attempts to "protecting your code".

1. JS/Html/CSS is usually quite easy to backward engineer, they don't need to look at your code at all.
2. Chances are, your JS inovations already exists and was written in 2001 by someone else.
3. The more complex the code, the harder it is to steal the intellectual property, especially if you opensource it.

There's really no sane reason to protect your code where JS/CSS/HTML is concerned, the best you can do is protect your business logic by keeping that on the backend.

Prime example, I could write my own implementation of CKEditor (a lot of people do just that) but it's a heck of a lot easier to just use CKEditor and everyone knows what it is, who wrote it etc.

Or take google maps as example, there are a lot of clones around, but there's only one real google maps. Heck, others had written a maps implementation before google, but google maps is more reknowned.

I could go on with lots of examples why trying to protect your code is not only silly, but actually not smart... Protecting business logic is one thing, but you actually have more to gain by going public with fancy smancy frontend code...

Dionysius

I agree with this answer: leading a good open source project can easily get you into google! And you get timeless recognition too. – Sequence

Answer 2

Regardless of how you obfuscate the code, anyone can replicate what you are doing just by seeing it. It might take a little longer to write it from scratch, but there's not much you can do about that.

Your only true options for protection involve copyrighting the code and, potentially, filing a patent. If what you are doing is truly different, then a patent is probably the best way to go.

Typically the value in your application is really going to be in the support area. In other words, people will buy it if they feel that you will be around long enough to support it. Be aware of this as you price it.

You're going to find that there will be some that will simply steal your code and reuse it. Don't worry too much about them as they weren't going to be paying customers anyway. Instead, make it easy for your own customers to buy and use your stuff. Make sure you provide support; that's where the real value is going to come from.

Twig

This isn't the first answer like this, but Chris is correct. If what you're doing is truly something unique, licensing and patenting is the route to take. You won't be able to stop someone from recovering your code, regardless of how you obfuscate it. Additionally, you run the risk of making yourself look bad to the rest of the development community by making a failed attempt at hiding what you're doing. – Sarson

Answer 3

No you cannot do that.

Everything is going to the browser (the client). You may obfuscate uglify, minify or whatnot with it, but at the end it's an easy shot to "encrypt" that again.

You can't hide it either, because you want the browser to receive of all you sources. So even if you do some funky move like, "loading javascript with dynamic script tag insertion and remove the script tags afterwards". Well that might work for some unexperienced users, but using a tool like Fiddler will show the truth again.

Heida

Answer 4

You simply can't do that. Obfuscating your javascript and CSS with a minimizer is probably the closest you can get.

Jamal

-1 That wouldn't help at all, there's beautifiers that will unravel the code as quickly as you can obfuscate it. – Pantywaist

@Steve - Yes, there are tools to undo minimization, but they still won't generate meaningful function and variable names from garbage. So the code will be somewhat more readable, but still difficult to decipher. – Jamal

Answer 5

Well, the popular answer is going to be "don't put it on the web". However, you can obfuscate your javascript so much that, typically, no one will bother stealing it. Removing function and variable names and the like goes a long way. Generally it will be easier to start from scratch.

Carib

That will probably be the solution I decide to explore. – Kimber

Having all your javascript in one file is also good for performance as well as obfuscation, maybe you could embed and hide your custom JS within a common, pretty inpenetrable JS library like jQuery. It's unlikely anyone would realise. – Josiah

@Andrew M, you just realized that. – Innocency

I don't see what kind of attacker you think obfuscation will protect you from. Typically, people won't bother stealing anything but trivial snippets of JavaScript even if you don't obfuscate it. The kind of people who casually copy and paste JavaScript don't want to deal with complicated systems. Hackers sophisticated enough to deal with a large, undocumented library will probably not have too much difficulty seeing through your obfuscation and ripping off anything interesting in your code. – Techno

"attacker" seems a strong word. All obfuscation protects you from is the lazy. However, I tend to think that people who steal code rather than write it themselves tend to be lazy. – Carib

Answer 6

Minifying your HTML, CSS, and JavaScript will help a small bit, but people can always reformat those. Your best bet is if the contents sent down to the clients aren't the same as the original contents that you're working with.

That can be achieved by:

• generating your HTML from some framework
• generating your CSS via SASS/LESS, etc.
• using a JavaScript compiler on your scripts (i.e. Google's Closure Compiler)

However, with all of those, there's only so far that you can go. Compiling your JavaScript will make it harder to follow your original intentions, but probably not difficult enough if someone sets their mind to reverse-engineering it.

Greenway

Answer 7

You can either not put it on the internet, or keep it accessible only via an intranet; but there's no way to reliably prevent the client from accessing the html/css/JS, without preventing them from accessing the site itself.

Obfuscation will deter casual attempts, and curiosity-browsing, but won't prevent a determined attacker/browser since it's all implemented on the client-side.

Kropp

Answer 8

You can use a JavaScript obfuscator. It will make the code difficult to read. They can still "rip it off", but it would be very difficult to understand it and therefore modify it. There is no way you can hide the code completely.

Macromolecule

Answer 9

I've thought about this problem a lot and, frankly, there isn't much which can be done. The best I've ever come across is using a JS compiler.

Theoretically, and I've never actually done this but I do know that it is possible, it might be possible to load your js through a 1x1 pixel swf which was in turn sent through a scrambler. It is still possible to get around that, but it becomes far more annoying. Then, you would be able to send aes encrypted code through to the swf, decrypt it client side (using as3crypt libraries), and then write it to the browser. That said, unless you were using the swf for a series of callbacks, you'd still have the problem of the fact that it would still need to be written to the browser. Firebug and the other browsers' js consoles would let the user get the "compiled" js. Of course, it is possible to script AS3 to register the series of callbacks...

As I've said, this is more hypothetical than not and while I've no doubt that it could work in idyllic situations, Flash is limited and you'd need knowledge of AS3. The benefit, of course, is that this is a way to get js to the browser without the user being able to read it easily.

Oina

Answer 10

I don't really believe it's possible to hide JavaScript code from the end user, JavaScript is done client side not server side meaning the better it is viewing the source code in plain text or having a third party program intercept the browser, end user, requires the code to complete the task.

Even if it's encrypted, at some point in time it is going to have to be un-encrypted for the browser to complete and show the task, where the end user will obtain the code, unless you have complete and total control over the end user's computer hiding any code which is executed client side would be impossible.

Perla

I found a way to protect HTML from theft. Encrypt HTML with symmetric key, encrypt that key with public key (Let's Encrypt), send both to client. Steps: 1. Keys: public/private (Let's Encrypt), symmetric (32-char random) 2. Server: Encrypt HTML & symmetric key, send to client 3. Client: Get decrypted symmetric key, decrypt HTML 4. .htaccess: Secure sensitive files Notes: - Combined CSS/JS into HTML - Encrypt whole HTML, decrypt before DOM insertion - Let's Encrypt can't handle whole HTML, hence key View source: all encrypted! Ugly but effective. – Cornelison