Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
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.
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...)
JavaScript codes are compact and dirty .
This makes access to the source code difficult and sometimes impossible
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am building a web application for a company so they can test the app on a control group of people to see if they would like to try funding the app. Funding beforehand is not an option, however I would like to keep the code somewhat private, so that someone from an IT team can't just easily download all the app files and claim it as theirs. I have researched a little but also found little on what can be done to protect the files for the app which are written in javascript, html, css, ect. basic web development languages. i was just curious if anyone knew of a way to somehow protect these files if it is even possible. I'm not against sharing my code, however for a business opportunity I prefer that it remain private for the time being.
This question has been answered before: How can I obfuscate (protect) JavaScript?
But anyway, here's my take on the question:
You don't need to protect your HTML/CSS code, unless that aspect of the app is what is so proprietary. If that is so, obfuscate your code (there are many websites online that will do this for you).
From the information you gave me, I can infer that it's not the styling or the UI you want to protect, it's the application's logic. In that case, you can obfuscate and then minify the JS code such that it's very hard to deconstruct (although some web browsers do pretty-print the code). To see an example of this, go to Google, open the dev tools, and look at any JS file under the Sources.
I also saw another interpretation to your question. If you meant "to protect the application from being downloaded and then reuploaded", that sadly isn't possible with web apps (unless you explicitly check the domain that the app is running on and restrict the app from running on domains other than yours).
An implementation of the domain-protection would look something like this:
if (window.location.hostname !== "yourwebsite.com") {
alert("Invalid domain, redirecting to official app...");
document.location = "http://www.yourwebsite.com/app/";
}
After adding this protection, you can stop it from being removed by minifying and obfuscating the JS code.
For the css and Js a lot of people use minification. This makes your code really hard to read and finding the business logic in your code. As for the HTML you could uglify it. There is no real way to hide HTML,CSS, JS in your browser because the browser dev tools would reveal all of the code. There are only ways to make it unreadable.
JS minification tool : https://javascript-minifier.com/
Css minification tool : https://cssminifier.com/
https://developers.google.com/speed/docs/insights/MinifyResources
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm a C# developer, and use XAML for user interfaces. Lately I've been wondering something regarding HTML5+JavaScript development (used in Universal Windows App development, as well as for websites). Javascript is compiled and executed at run-time on the client device. So any user can go into the folder where they're stored on computer, and see all the code in it, right?
There is no unreadable alternative for js and html5. That's why so many websites are so slow in adopting html5 video and replacing adobe flash.
But if your entire application is client side and you worry about your code being stolen you're doing something wrong. Almost any application requires serverside code that isn't accessible.
And it doesn't matter anyway, who cares about some js that makes a div draggable or moves some html around.
I dont think readable javascript code is of any value...what matters is the server side code like php or ASP which really matters in the security of the websites
And even if the developer didnt want the user to read the javascript framework.. what option does he/she have to prevent it..?none!
The client side code is indeed visible by the client. If something is available client side, then you won't need a round trip to the server to get it.
For example you could imagine a simple calculator application. You could write it client-side, in Javascript, the app can ouptut the calculations immediately. Or you could write it server-side (in wathever language you want), which means you need to ask the server for the calculation (with an ajax request probably), and wait for it to respond.
Also some things doesn't make sense on the server-side. Pretty much any action that changes the DOM, which only exists client-side, in the browser.
I wrote about this on my blog a while back, see Protecting Your Code,
as an addendum to my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition.
The short of it is that JS code it not protected, though you can make things a little more difficult with minification/uglification like many website authors do. You can also take steps by putting some of the code you care about into Windows Runtime Components written in C++ (C# can be decompiled). The only really secure solution is to have code on a server, and draw from that in an app which of course doesn't work for all cases, but is an option.
Note that some of my comments in that blog from 3 years ago might be a little dated. I believe that current Windows Store policy now allows you to load code from a remote server at run time.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Most traditional MVC frameworks include their own templating solution (Jinja2, Mako, etc). If one decides to use one of those new ui frameworks such as angular or backbone, they seem to encourage the use of front end templating solutions.
Is there any difference in performance? What are the pros and cons of going either way? Are there issues in ie or other browsers when using some of theses js templating solutions?
My take on this is simple, really.
Use a server side templating engine when you want to template the structure of a site. Use a client side templating engine when you want to template the data of the site. And there is nothing wrong at all with using both, as long as they don't have a large amount of competing tokens.
A VERY common example of this is using ASP.Net MVC to manage the bulk of a site structure using the razor template engine, and using a JavaScript client library such as Angular.js to simplify the data structures on the individual pages.
Depending on the situation, one major factor can be a significant change in bandwidth usage.
For example, my newest project includes the ability to have colour codes in chat (and other places). These codes look like:
`1blue `2green `3yellow `4red `bbold on `Bbold off `b`iBold Italic...
I could parse this server-side and return:
<span style="color:blue">blue </span><span style="color:green">green</span>...
But see how I only did two words and I'm already going longer than the source text! Instead, I chose to implement the parser in JavaScript, on the front-end. This takes a lot of processing off of the server (which would otherwise have to parse this stuff for every single user) to the client (where only one user is being dealt with).
It also had the advantage that I could implement a live preview just by plugging in to the same parser, but that's irrelevant here.
Additionally, client-side templates can be cached, further reducing the amount of data that needs to be sent. This can be particularly beneficial to mobile users, who may not have unlimited data (those poor people... I weep for them... not really)
Personally, given the choice, I'd strongly recommend client-side templating (although in my usual style, I would shun all pre-made solutions and make my own XD I'm weird like that) for a variety of performance reasons. Obviously, the major downside is "no JavaScript = no website", but I'm fine with that since the entire site relies on JS...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
There are a lots of new frameworks, technologies coming up. And it's becoming so hard to follow up all of them. One of the thing that confuses me is client side frameworks. I heard that Angularjs,Backbone,Knockout,jsviews,knockback, SPA... are the most popular right now.But I can't understand how does the security concept applies? If we take an example of querying a table form database it's now possible to make queries from client side database, by specifying table name and fields and etc... So if it works that way, than everyone else can write another query and get all other information. I am pretty sure that I am missing something very important here, and it doesn't click my mind. So please can anybody explain me where can I start learning those primitives.
I really appreciate, and I am really eager to learn but I am searching it wrong way I guess.
Whatever the framework used, the security matter will still the same, and very similar to mobile apps:
which data can you afford to be handled in an untrusted environnement
which treatment can be applied in an untrusted environnement
By "untrusted environnement" I mean the browser itself. You have to understand that any code executed in the browser can be corrupted by a medium/good JS developper.
Data security suffer the same threat: giving access to data from your client means that you do not control anymore who is using it.
Once you've dealt with this simple matter, it became easier to decide what must stay on server side, and what can be deported to client.
That said, there are various ways to make data/algorithm steal more difficult:
Obfuscation that comes with minification
Double data validation (forms for example): both client and server side
Authentication protocols, like OAuth
Binary over webSockets, instead of plain json and ajax call...
The browser sandbox imposes some limitations, but mainly to protect the local computer from damages due to malicious JS code. It does not protect your code nor your data from being seen and manipulated by the user itself.
I am using angular for some of my projects. I haven't used other frameworks , but in angular you usually consume an API to get the data. You don't query your database directly. So, the responsability of securing your data is more in you API (Backend) than in your angular client.
You can use OAUTH, or other security method that you want to make your api safe.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Similar to this question; When to use JavaScript template engines? but not quite.
Is it practical to make full sites (e.g. skip static HTML and PHP processing and just send JavaScript with HTML templates for client side rendering) in client-side JavaScript with a template engine such as handlebars? Or, are template engines only useful when it comes to re-usable template sections?
You have half of the the answer, which is re-use, but you can get that on the server-side. To me the other half is as follows:
Allow front-end developers to handle all the interactive development in JS and HTML, almost without knowing JS for simple templating needs.
For web applications the UI rendering on the server slows or limits the interactions/experiences one can design, or at least limit performance. Why does the server have to know and understand the User button clicks? The browser is powerful enough to handle the button clicks.
It pairs nicely with REST services. The browser knows how to request the data and determine the user context.
More complex web server side design. State is a very complex thing to manage across clusters and nodes. Not that you can't but why should you? Especially as for most modern web applications (web 2.0 and all that jazz) the whole point is the browser doing more, handling button clicks, sorting data, etc. Guess what all that is user state. So the browser already has a lot. So why distribute that state across a cluster of servers adding latency, dependencies, etc. I have a no HTML in the application server policy.
Change control. When you write PHP and embed HTML snips in everything things end up tightly coupled. It reduces flexibility of use case changes.
Separation of concerns, forcefully. Many developers are tempted to do business logic in the view. Simple templates help reduce the likelihood of this. One could easily construct an argument against all non-templating based approaches, JS or server-side but that is not the question at hand.
If you are going to build a mobile app you want and need services that avoid presentation markup. So never generate HTML in the application server or else your app will only speak one language. People might shout server side MVC will help, but not for off-line, different access patterns, etc.
There are some performance, device detection, 'dumb phone' reasons to generate html server-side, but then write it off of the services which your JS web app use. Let that be the exception. Even better write it in JS on the server-side and re-use the business functions and logic on both.
I use a JavaScript template engine when I make one-page web-apps (with backbone.js for example).
In any other case, I would not use a JavaScript template engine.
The reason for this is, that if I create an application in anything other than JavaScript-only (PHP, Rails etc.), I like having the templates done on the server rather than at the client.