Is Angular JS secure?

[akshit mahajan]

Hi,

I am very new to angular JS, I read a few posts online that angular JS is not a good choice security-vise.

Since all the business logic that is written is present at the client end(Browser), any hacker can attempt to hack the business logic easily!

What are the expert's comments/suggestions in this scenario?

[Alec Taylor]

You could always minify it as a way of obscuring your code.

"Hacking the business logic" though; isn't so bad. Who cares if people know the regex I use to validate email addresses?

Any decent Software Engineer can reverse engineer Facebook's feature-set. Does Facebook care?

The actual security of user authentication and the data itself on the otherhand; you should care about.

Hash+salt all passwords; and encrypt (TLS) all channels between server and client.

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Raul Vieira]

The server owns your domain rules and is considered to the master while the client should really own presentation logic.  You can never trust the client.  The idea gets a little blurry though when we consider a client where the source is not accessible ie a hybrid mobile application with the source included in the app's distribution.

Raul

[Jeremy Likness]

Angular is no different than any other browser-based technology. It is completely your choice to decide much logic runs at the client vs. the server and what trade-offs you are willing to make. 

What "business logic" is it you think will be hacked? Do you have a tangible example? For example, if your company has some special algorithm for determining how many widgets are going to be sold over the next two weeks, there is nothing in Angular to prevent you from hosting that algorithm on your server and just exposing the result as a web service end point. Angular's interceptors give you control over headers for authentication and to avoid cross-site forgery, etc. so I'm not sure I buy the argument that it is any less secure than the web in general, and if anything I'd say it supports making your apps more secure.

Jeremy

[José Ricardo Borba]

First point: web is insecure;

Second point: the only way to keep your business logic secure is to keep it in the SERVER side.

Third point (optional): use Angular for presentation only. Is what I do.

Best regards,

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

--

José Ricardo Borba

[calvin crane]

I still am not sure that server side is fully secure but I do know its a common belief.
Server side with correct sever admin helps secure the source ok and that can include for example a private app key.
Server side requests data via http for me sends out API secret and token for example using foursquare app - this is no different in my mind to sending via the client. This is all unencrypted info that is available just because it runs on the server there is no magic backchannel ?

I realise I don't help the OP here but am kind of asking for your guys input to help my own thinking.

[Alessandro Ghidini]

Calvin, you're talking about a channel security problem, not a client side tecnology issue: whenever you're handling critical data you need to secure and encrypt your channel at least with SSL (talking about the HTTP layer). What you may consider critical belongs to your specific domain and business rules but, surely, it includes the authentication phase with login/password or with an api secret.

Akshit, you're right, Angular is not secure and a skilled user will be able to read your secret business rules, if you decide to embed them in your client side sources, simply because your javascript files are a F12 button away to be visible to the web application users. This is a javascript "limitation" though and it influences every client side framework as it does with angular. This is the reason why they say that "you don't have to trust the user": you should use the client side code to improve the user experience, like performing basic client data validation avoiding useless round trips to the server, but the "real" business rules have to be present on the server where you'll have to execute again the validation you've just done on the client along with the authentication, authorization and any other verification checks needed by your use cases.

Alessandro Ghidini

[Calvin Crane]

Thanks so I feel I may be right and this means for any non http request to an api server side like foursquare will reveal the secret key unless we do the hashing ourselves. And for me that is a key concept as it therefore is the same as doing it client side. Both are insecure is my point.

Calvin

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/iATsJIDlIGU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.

[Sander Elias]

Calvin,

You are mixing up the definition of secure. In this case, they question was about business logic. If you keep your business logic on the server, it will be secure, as in that the user can not get a look at the CODE running on the server. Anything you put in the browser can be examined by the user/hacker/whatever!. So, don't put your algorithm that puts you in front of the competition inside the browser! 

Then there is the point of being secure in communication. This is where you seem to aim on. This is something different. you can never be secured of the thing your server is talking to. There are a few things you can do, but 100% (or even 95%) security is not  obtainable! If anyone does keep a different opinion, show me! I really would like to achieve this!

the things you must/can do to keep your data/users safe.

1. use HTTPS, allways. 
2. don't use 3rth party hosted stuff. (not talking about known CDN's)
3. use HTTPS!!
4. only include trusted script!
5. use HTTPS!!!
6. Only communicate to trusted resources, and double check those regularly!
7. no ads
8. use HTTPS!!!!

google arround on what can be done on security. Google the stuff you are using in combination with security. Don't forget to check all plugins/libraries/frameworks you are using.

With that out of the way, besides (possibly) exposing your business logic, AngularJS is one of the most secure frameworks around. It protects you against a whole slew of possible security vulnerabilities, where other frameworks/tools do not protect you at all!

Regards

Sander 

[calvin]

Thanks for the clarification and the helpful reply. I must admit the docs on $sce and $sanitise and others might give the wrong impression and I didn’t find a really good easy to read post on the security benefits of Angular.

[Alessandro Ghidini]

I don't know the foursquare API details but, in general, you should never send any authentication key on an unsecure channel.
When accessing a resource from a web application you normally authenticate someway first and then you call its services directly relaying, normally, on the authentication cookie established earlier. When you access it through an app, mobile or desktop, and you can have a secure store for your secret, you can have an initial login/password authentication for exchanging the secret some way, store it, and then use it for hashing your requests. This way your secret will never be transmitted again but remember to include at least a timestamp in your hashing procedure in order to make your request expire.

Anyway, security is a very difficult problem and the attack surface is huge. Don't try to reinvent the wheel on this topic and try to use what is already implemented and the best practices of the technology stack you decide to build your application with.

Oh, spend some time on https://www.owasp.org/ , it will not be that funny, probably, but it definitely worths the time.