Since I’m new to the Ember concept, one thing that I’m a bit concerned about is the security aspect. I am using ember-cli and ember-data with a private app that I plan to deploy on the cloud. A few the concerns that I have is that:
- The whole app is in 1 js file with all your ember data model objects giving a fairly decent idea about how your back end is structured.
- The output of dist in ember-cli doesn’t necessarily appear to be very obfuscated.
- Ember Data itself and the Ember Framework is extremely powerful, yet designed in such a way that the front end app basically contains all the business logic in it and makes REST Calls to a back end that basically just provides CRUD rest endpoints. The problem I feel is that if somebody get’s a hold of your .js file, they seem to have access to all your Entity Relationship model as well as all your business logic in that 1 JS file.
To mitigate my concern, I’m including my ember-cli app inside of a rails app so that it is secured by authentication, authorization and the CSRF Token.
I would like to understand if my above concern is valid, and also what others are doing to mitigate these risks when writing a private app with ember where you don’t necessarily want a user to really be able to understand and have easy access to your ER Model and Biz logic just by looking at your .JS file.
Ember seems to be very mature and highly used, so I’m sure that the concern I have is more of a Newbie concern, but yet I would appreciate some insight into this.
Amarish
1 Like
Ember is a frontend framework, so all security has to happen on your backend.
If you are shipping the code to the client, anyone with access can read it. Putting the code behind login with rails would stop unauthorised people seeing your code (as long as you ensure you are actually authing access to the file, which is not the case by default for rails static assets).
Authorised users can see all the code and will be able to work out your business logic. If you don’t want them to have access to this then don’t ship the code to them. This is not a common concern for people to have, so if you have it ember is not a good choice of framework for you - neither is any javascript framework or a client-side architecture in general. Production code is minified by default but it’s very easy to unminify javascript code. In addition, a tool such as the ember extension provides a nice graphical view of everything that’s going on in your app and would work with even extremely obfuscated code.
Can you elaborate why you wouldn’t want authorized clients to see how your app is structured?
I would like to understand if my above concern is valid, and also what others are doing to mitigate these risks when writing a private app with ember where you don’t necessarily want a user to really be able to understand and have easy access to your ER Model and Biz logic just by looking at your .JS file.
If this is a concern, you would not write your app with javascript.
Hi Alex,
Thanks for your reply.
I am trying to choose between Ember and Angular. I prefer Ember architecture wise, development wise etc. However, what I do see is that if I use Angular and use the modules concept in Angular, my app doesn’t go to the client all in 1 go and the client cannot really see my data model.
However, I see your point about authorized users. I guess it’s more of an uneasiness factor. I come from a Services Oriented Architecture JAVA background, so I’m really not used to this concept of biz logic and domain models living on the client side and being downloadable by a user that is logged in which is what ends up happening if you use Ember and Ember Data.
Amarish
@akhopkar if you’re using a rails wrapper you might check out GitHub - ember-cli-deploy/ember-cli-deploy: A deployment pipeline for Ember CLI apps
I’ve ended up splitting my application into separate ember apps and deploying them at different urls. Using the above method and sharing code with ember addons. My application happens to have some very clear dividing lines in it, so it may not be possibly for you, but if you do have those dividers this is a pretty nice way to avoid sending unnecessary code to the client.
I would second @alexspeller point that depending on security by obscurity is not possibly in javascript nor is it really a good idea in any language.
@varblob Thank you for your reply. I may actually consider this. I actually looked at ember-cli-deploy.
However, what didn’t seem spelled out was:
- I want to secure access to the ember app itself (not just the REST calls) so that it is downloadable only by authorized users.
- I obviously want to also secure the REST calls.
- Clearly I don’t want double login (once for the web server and once for the back end server) so there needs to be some sort of single sign on mechanism or token or something.
If you split the 2 is there an easy way to achieve the above 3. If so could you please point me to the right direction?
Hi Amarish!
Obfuscation is not a valid security approach, in any framework. Whether it
comes in one chunk or many, an easy inspector tool or not, anyone dedicated
to cracking your app will easily be able to do so with any client-side
“security” approach. Angular and Ember (and Backbone, React, Knockout,
whatever) are identical in this regard.
As Alex says, your entire security strategy happens server-side. The
typical approach is something like:
- User submits credentials to a server
- Those credentials are validated and an token is sent back
- Every data request is signed with the token
- Server data requests check if the owner of the token is authorized to
make the request
Another way to think about it: A user should be able to know your entire
architecture, and you should still be able to secure the app. This is the
principle behind most open source code. This can be hard to swallow if
you’re from an enterprise background, but it’s worth the time investment to
learn.
1 Like
Ok thanks for your input Kyle.
I guess what this means for me is that since I want the ember app itself to also be served to authorized users, I will keep it inside my Rails app and will secure access to the ember app itself to authorized users only.
Also, I will secure my REST Calls through the back end. So I think rather than the ‘split’ option, the embedded option will probably work better for me.
Yes but still, how do you obfuscate using ember-cli. For instance, I have a JQuery plug-in that has an easy to user interface. One might not want your everyday amateur to be able to pick it up and use it. So you obfuscate the plug-in making it generally unusable for your hobbyist.
Whenever someone asks this question why is it always shut down saying “oh security should be on the server-side” , its a completely valid requirement.
Security is a mostly server side responsibility. XSS is something that is protected on client-side. All other attack vectors are protected via server-side setting appropriate headers (CSP and others).
Obfuscation is for the purpose of security is just security through obscurity. It is not a recommended practice.
Minification performs obfuscation to some degree and is done automatically with Ember’s production build ember build --environment=production
Yes it is, but security is not a black and white manner, it is on a spectrum and it depends what you aim to “secure”. In the real world you have “levels” of security. e,g a passcode entry machine on my workplace office door is a level of security but not quite secure as anyone can pass codes around. But it has a purpose and a function and suits the purpose it is there for, or is a best approximate.
It isn’t relevant at all to say:“Security should be on the server side”. The server cannot prevent users from seeing client-side functionality unless that functionality is implemented on the server, which is not always possible or appropriate to the technologies being used.
Obfuscation is a level of security and will help stop people generally deciphering the operations with ease. Also security is traditionally a multi-pronged approach.
On top of everything, you may well have secured the app on the server side and simply want a further measure on top.
I’m sure someone can write an addon to pipe everything through jsfuck
2 Likes