If we want to deploy our NEST.js sever on the customer's environment, how can we hide our source code preventing from the plagiarism?
Unfortunately it is impossible to completely hide your package implementation. What you can (and should) do is using Webpack to create a bundle and minify your exported code. With that, it is pretty hard for someone to reverse engineer your code, but it is still doable.
Since Javascript is not compiled to binary, the executable of your code will always be Javascript, therefore it could be reverse engineered.
Related
We are using Angular for front end and Node.js for backend. We are in conversation with a client to run our application on their local server, hence if we could use a package executable of the application, it would not give them access to our source code. We want to know if there are any robust tools that can help us do this or if there is any other way in which we can allow them to use all our application's offerings without giving them any idea of how the application works technically.
I think you have next options
compiles your backend part into a single executable file nexe
encode your critical parts to weird format weird
run your backend part in docker after minifier/compressor tool minifier
compiles modules to binary format binary
mix all options
I am about to begin the process of creating a Windows-based utility app to manage localized expressjs server that will utilize a graphical Windows based application to manage some of the features of this service
however before I begin I would like to speak with the community to try to get some advice Advice on how to properly protect the code since it will all be node JS bees I need to make sure it’s protected and some of my initial reading online seems to show that using electron by not be the most Safeway saw that being said how are you guys handling this to keep node JS these code protected with electron and in my case On windows environment
Any advice would be greatly appreciated much thanks
tl;dr You can and it is not worth the effort. Just pack your source into an asar file, it keeps most people away from it.
Long answer:
Use the asar option when building your app.
Obfuscate the code with an uglifier.
Use WASM
Language bindings to grab your data from a compiled format
neonjs for Rust
edge-js for C#
N-API, NAN for C/C++
Otherwise, your files are scripts, all these steps only slow down an attacker (tactic of many defenses), but they will not prevent them from accessing them. The devTools are fairly easy to get opened and people will be able to read the code in some way, shape or form. And if someone gets your obfuscated code, it is simple to reconstruct what is happening (see here for reference: https://www.youtube.com/watch?v=y6Uzinz3DRU)
If you want to protect yourself from code manipulation, there are better ways to do it, like Hashing, Context Isolation etc. Electron has a whole chapter on the matter.
https://github.com/electron/electron/blob/master/docs/tutorial/security.md
Small Update (2020):
I've seen this library a few weeks ago and thought it would show a nice way to further obfuscate the code from being read by external parties
https://github.com/OsamaAbbas/bytenode
The basic idea is to compile the JS into bytecode for V8. This works very well for Electron and is definitely a hurdle not everyone will get over. But, this will not protect your code from being turned back into readable JS. It's just another layer of protection to make it more difficult.
Are there any existing solutions for run-time bundling of ES6 modules?
I'm looking to simplify JavaScript code development in a MVC5 web app. We're having issues with large, unwieldy JS files, so I'm hoping to get a module loader system in place. So far, I'm not finding any existing bundle transformers for ES6 or another module loader format. I'd be fine with using TypeScript or nodejs require style. I prefer not to use require.js style, though.
Perhaps there's a good reason this solution doesn't exist already. Maybe the dependency resolution processing is too much for a run-time bundling solution. But, I figure it's worth a shot to ask.
Solutions Considered
Prebuilt Web Client
Ultimately, this is where I want to be, but I need a stop-gap solution for now. I know how to put together a build system for an HTML client using grunt/gulp/webpack. But I don't want to have to tell developers to run webpack -w or something similar during development. Nor do I want to tell them to rebuild a solution for every JS change. They should be able to modify the file, refresh the browser, and see the change.
Directory Structure
This is the route I'll probably end up going with. Basically, this JS codebase consists of jQuery widgets and plain JS (helpers/common functions). So, if I structure the code in this directory structure and include the js dir, it should get me most of the way there:
js (DIR)
app-start.js
helpers (DIR)
widgets (DIR)
Widgets should be fine. Helpers, I can see issues where one function/class depends on another. Though, since a function call should never start with a helper (only a widget), this should work fine, assuming no globals are used (or maybe one global like 'App').
I'm developing a private web application for a company and they ask me to use their server to host it. I would like to prevent them the access to the source code. How can i do that? Their server is running debian and they have the root access..
I found some solution like packaging the application in one executable file but the application have lot's of dependency and I'm using loopback.io framework; this make packaging very difficult..
Any different solution?
The answer is no, you cannot prevent them from seeing the source-code. If they own the source-code, then it is even unethic to want something like this. If you own the source-code, then minify it. But before you do that, think about it. Will it raise the trust of your client in you? Even binary source-codes can be reverse-engineered. With interpreted languages, like Javascript, you cannot even do that. If you are afraid they will not pay you unless you protect the source-code, then implement the project on a local server and create a video to back up your claim that the project is completed. Although, everything depends on the actual agreement, which, you understandably will not share with us.
You can't prevent them from seeing the source code, but you can make it harder to read with browserify and uglifyjs:
browserify index.js --no-bundle-external --node | uglifyjs -c > bundle.js
This unfortunately won't preserve the original stack trace of errors and will make it harder to debug.
first things first , i have seen nwsnapshot. and its not helping.
i am building an inventory management system as a desktop app using node-webkit . the project being built is using compoundjs (mvc javascript library). which have a definite folder structure (you know mvc) and multiple javascript files inside them.
the problem is nwsnapshot allows the app to have only a single snapshot file but the logic of application is spread over all the folders in different javascript files.
so how do i secure my source code before shipping it to client? Or any other work-around Or smarter way (yes, i know about obfuscating).
You can use nodewebkit command called nwsnapshot to compile the javascript code into binary which will be loaded into the app without specifying any js file
nwsnapshot --extra-code application.js application.bin
in your package.json add this:
snapshot: 'application.bin'
It really depends on what you mean by "secure".
You can obfuscate your javascript code fairly well (as well as potentially improve performance) by using the Google Closure Compiler.
I'm not aware of any off-the-shelf solutions to encrypt/decrypt your javascript, and honestly I would question the need for that.
Some people think they need to make it impossible to view their source code, because they're used to dealing with compiled languages where you only ship binaries to users. The fact is, reverse-engineering that binary code was never as difficult as some people think it is, so if there's any financial incentive, there is practically no difference between shipping source code and the traditional shipping of binaries.
Some languages have offered genuine encryption of deployed assets, such as Microsoft's SLPS. It seems to me that the market for this was so small that Microsoft gave it to a partner (just my view). The truth is that most customers are not interested in taking your source code; they're far more interested in your ability to service and support that code in an efficient manner, while they get on with their job.
You may consider to merge the JS files into one in the build process and compile it.