Reputation: 27547
I've been using AngualrJS and Batarang (the chrome plugin for inspecting $scope variables). And I noticed that you can actually inspect the scope even in production.
Let's say there is a site with a page that has a scope variable $scope.permitted = false
and in the view there is `ng-show="permitted" that hides a div full of top secret info. Couldn't I theoretically just go into the console and run:
> $scope.permitted = true; $scope.$apply();
And then see the top secret info?? Isn't this a huge security hole for all angular apps? So angular shouldn't be used to show anything sensitive?
Upvotes: 0
Views: 270
Reputation: 1246
To be clear, this has nothing to do with Batarang. If Batarang didn't exist, that still wouldn't stop someone from inspecting the source, opening the JS console, and changing variable values. And this is obviously true for any Javascript, not just the AngularJS framework.
Client-side mechanisms, regardless of framework, shouldn't be used to handle the authentication/authorization itself. This would be equivalent to using a CSS style of "display:none" on DIVs that you don't want someone seeing. If it's just a desire not to clutter the screen, but not a security issue, then it would be fine (whether using CSS or AngularJS or any other client side approach). If instead you actually have data that the user is not authorized to see, then the API that you are pulling data from should be handling the auth and would only be returning data that the user is authorized to see.
Final example: you can obviously use javascript (irrespective of whether you're using AngularJS) to write a login mechanism -- including checking the entered username/pw against an object that has acceptable usernames/pws. This would obviously be a horrible security approach, since you can simply view-source to see the acceptable usernames and passwords. This in no way means that JS is insecure. It means that you have to use the tools in an acceptable manner and using client side JS code to handle the actual authentication portion is certainly not acceptable from a security standpoint.
AngularJS should be used to get information from an API that is handling the authentication/authorization. All data returned to AngularJS should be "allowed" to be seen by the current user. Directives such as ng-hide, ng-show, etc. should only be used for UI purposes to hide/show things that the user is allowed to see, but are needed to be hidden or shown for interface purposes.
Upvotes: 2
Reputation: 19802
Your question assumes that AngularJS as a framework (and Batarang itself) are directly at fault for these issues, which they are definitely not.
It's not a "security hole" in and of itself. Any client-side user authentication is a potential security hole; that's why you should do authentication for the really important stuff on the server.
As far as just showing or hiding views for UI purposes, using things like permitted = false
is usually okay, but you don't want to hide a page using that method that requires user authentication.
It's not AngularJS's or Batarang's fault; it's the fault of the architecture of the app and security practices you choose or choose not to use (by the way, many of the same things are possible just using, for example, Chrome's console. The issue you point out isn't just related to Batarang). That's fundamentally why authentication is handled on the server: because JavaScript is client-side, and users on the client have access to tools that can manipulate it.
To answer your question "So angular shouldn't be used to show anything sensitive?": Exactly.
Upvotes: 2