0

I'm not sure whether seeing these directives in plain text poses any particular threat to our app hacking or not. But if nothing else one can clearly see our model structure and functionality. If Angular removed those after bootstrapping it would at least make it a bit harder to access...

Two questions

  1. Would it be possible to remove all custom ng- attributes from markup after Angular app boostrapped? Would the app still work as expected?

  2. Would it be possible to dynamically add ng- attributes on DOM Ready using jQuery, and then remove them as per #1? If this required manual app bootstrapping so be it?

By having the possibility of the #2 somehow we could externalize app configuration and HTML markup would never show any declarative directives (just in the time between configuration-bootstraping-removal). But at least there would be none if user disabled Javascript.

Siguza
  • 21,155
  • 6
  • 52
  • 89
Robert Koritnik
  • 103,639
  • 52
  • 277
  • 404

1 Answers1

2

Anything that you expose via Angular will have to be exposed in some way anyway to the client if the client is supposed to show some data. If you want to have an interactive client-side application, then it needs to have some form of client-side model and data structure and code working on those things. Whether you express them purely in procedural code in a .js file or embed part of the structure into the HTML markup hardly makes any difference. It does not make anything any more hackable which wouldn't already be hackable to begin with.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • I agree on that but I still believe that *stealing a parked unlocked car with doors open* is much more tempting than doing the same with a locked one... Wouldn't you agree? If what you're saying was all true there wouldn't be no need for code obfuscation tools, would it? They don't prevent hacking but they make it a step harder. – Robert Koritnik Jan 08 '14 at 11:44
  • Well then, please define what there is to "steal" to begin with. A car can obviously be stolen. Yet there's nothing obvious that can be "stolen" here that couldn't be stolen otherwise. – deceze Jan 08 '14 at 11:48
  • It's an analogy. It's not about stealing but business rules hacking thus trying to break the system – Robert Koritnik Jan 08 '14 at 11:49
  • So again, what is there to "break"? Client-side code can never ever be secured by anything, whichever way you package it up. And client-side code can also not be in any way a component in your security infrastructure. The only thing that could be "broken (into)" is your server-side API, which you need to secure so it cannot be broken. This has nothing to do with Angular whatsoever though, the server-side security you need to have either way. – deceze Jan 08 '14 at 11:52
  • Valid points valid points... I was just thinking whether that would be possible, but instead of answering whether #1 or #2 are possible you're telling me why it's not relevant. **Even though it may not be relevant it may still be possible.** Right? – Robert Koritnik Jan 08 '14 at 12:23
  • Yes, it's completely irrelevant, I'm telling you you're wasting your effort barking up an irrelevant tree. As such, and because I have no practical experience with Angular, I'm not going to advise on your actual questions. I would *guess* that it will be rather disruptive to the functioning of your Angular code if you mess with it in this fashion, but again, I do not know. I am pretty positive that it won't increase security in any way though. – deceze Jan 08 '14 at 12:30