I was talking to someone that was saying that frameworks like Angular, Vue, or React have a big drawback: except the API part (the interaction with the DB on the server), all the other code is visible from the frontend, so anyone can steal your app.
-
3Is there a question here ? This is the definition of JS, nothing more ... – Sep 25 '19 at 07:46
-
1Yes all code is visible, but we usually minify code so that it is difficult to understand. Therefore we should not be adding any confidential information like secret api or credentials in frontend code. – tarzen chugh Sep 25 '19 at 07:47
-
3@explorer the guy asked questions that got a lot of points, that's why he has points on those tags. It doesn't necessarily means he is a JS expert ... – Sep 25 '19 at 07:48
-
3JavaScript code is exposed in the first place regardless of whether using a framework or not – zmag Sep 25 '19 at 07:49
-
@Maryannah their top tags are (in order) `javascript` and `jquery` – VLAZ Sep 25 '19 at 07:56
-
To add about minification thing, good luck stealing this code https://imgur.com/a/ffiYWKD – SLCH000 Sep 25 '19 at 07:56
-
@SLCH000 what's the problem with it? The browser itself already indented it properly, and that's honestly the biggest problem. Sit down and rename the variables to something more sensible and you're done. – VLAZ Sep 25 '19 at 07:58
-
2I can't believe the upvotes. _"Client-side code is client-side, amirite?"_ really makes a good question? – mbojko Sep 25 '19 at 07:59
-
@VLAZ i think such work would be equal or worse to writing code yourself at this point. – SLCH000 Sep 25 '19 at 08:00
-
@SLCH000 it's still easier. A simple rename will take a minute or two and most of it is just finding where the variable is used and how. – VLAZ Sep 25 '19 at 08:01
-
@VLAZ and look from where the points come from, you'll understand. – Sep 25 '19 at 08:04
-
Strongly related, I'm not even sure if it's not a dupe target: [Why is client-side validation not enough?](https://stackoverflow.com/questions/3483514/why-is-client-side-validation-not-enough) - it focuses on the fundamentals *never trust the client*. – VLAZ Sep 25 '19 at 08:05
-
Also related to trusting the client: [Is client-side validation unnecessary?](https://stackoverflow.com/questions/23883588/is-client-side-validation-unnecessary) – VLAZ Sep 25 '19 at 08:06
-
1As it was noted, it's strange that you're concerned with frameworks. The problem is totally applicable to any JS app. If you care about stealing, you can move some crucial parts to backend at the expense of extra API calls. Minify/obfuscate JS code AND use auth for source maps. The use of exotic compiler like Dart or Scala.js may make stealing less appealing. The answer has a good point about Wasm. That's pretty much all you can do. – Estus Flask Sep 25 '19 at 09:09
2 Answers
This is a fundamental fact of writing rich client-side behavior, it's nothing to do with the frameworks. It's to do with having client-side logic. The same issue exists for sites that use, for instance, jQuery, or that manipulate the DOM directly. The primary protection of your work isn't obscurity (hiding your code), it's copyright law.
The fact that the code is client-side has several ramifications:
- Regardless of any rich behavior you implement on the client, you must validate all actions and inputs on the server as well.
- If there are business processes or calculations or similar that are trade secrets or proprietary, you must not implement them client-side, because whether you obfuscate the code or not, it is visible and can be seen by others.
- And yes, it means that anyone can steal the client-side parts of your application. The only thing preventing that is your copyright.
But again, that has nothing to do with the frameworks. It has to do with implementing part of your app client-side.
A side note about frameworks: It's becoming more and more popular to enable server-side rendering (SSR) of code written for frameworks like Vue.js, React, Svelte, etc. So using one of these frameworks doesn't necessarily mean you're writing client-side code: You could use it only for server-side rendering.
There is one interesting thing that's happened recently that's potentially making it much harder to reverse-engineer client-side code, though: WebAssembly. With WebAssembly, what's delivered to the client isn't JavaScript code, it's WebAssembly bytecode. Like Java bytecode, you can reassemble source code from bytecode, but it's a very messy process and the results are very hard to use. So, like really thorough obfuscation, it raises the bar, makes it harder for someone to take your work and reuse it. But it only raises the bar, it doesn't prevent it. (This is a side benefit of WebAssembly, not at all its main point. The great thing about WebAssembly is that it can be the output of compiling any number of other languages, including C, C++, Rust...)

- 1,031,962
- 187
- 1,923
- 1,875
-
"*The primary protection of your work isn't obscurity (hiding your code), it's copyright law.*" I don't know if it's worth adding a few words in the answer about that. Since, I find that a *lot* of people are not familiar with the fundamentals: *copyright* is you own anything you create. It's automatic, you don't need a license or a copyright notice. You can opt-out but you have to be explicit. Copyright protects you from somebody taking your creation and using it. You can apply for a *patent* is also an opt-in protecting inventions - algorithms or applications can fall under this – VLAZ Sep 25 '19 at 08:17
-
Finally, a *trademark* is an opt-in(-ish) basis and deals with identifying a business. – VLAZ Sep 25 '19 at 08:17
JavaScript codes are compact and dirty . This makes access to the source code difficult and sometimes impossible

- 148
- 11
-
1"*and sometimes impossible*" it's ***never*** impossible. It's difficult at best but anybody who is at least moderately motivated will not be deterred - there are plenty of tools that make reading minified code easier. – VLAZ Sep 25 '19 at 07:57
-
-
1Yes, that's right. Your sites should be such that you do not bring any information to the web page. Define information in Private variables to prevent them from being directly accessible. However, they are still available – Reza Yousefi Sep 25 '19 at 08:08