sabato 21 febbraio 2015

Security using client-side javascript frameworks

In a previous post I put the focus on the security of Angular.JS.

I found a quite easy way to solve this problem:

the problem simply... does not arise.

I am going to explain a bit deeper this concept.

Usually security has to address one main goal: allow to access data/services only if the user has the right authorization.
There is a second, less important goal: adapt the presentation layer to the gained authorization.

Example: if I do not have the the authorization to change the info in a form, the "save button" should be absent on the page!

IMHO this is the real difference between standard "server-side-generated" page (php, asp.net,....) and "client-side-generated" page (Angular.JS,...); this difference can be summarized in this question:

"Who is going to decide if the button should or should not be shown?"

The first solution solve the complete security logic server side, sending to the client only the strictly necessary functions (if not authorized, the server will not even send the the button to the page), while the second solution delegates part (even significant one) of the security logic to client side.

This means that, Angular.JS (as every client side technology) can not solve the security issue itself: all the security logic has to be addressed by separate APIs entitle to check every service exchange among client web page and server web app.

But,even if I put in place this logic (server or client side) I should not forget to put in place the main security check: verify that the operation put in place is allowed!

Conclusion:

Working with client side logic helps a lot to focus on security issue leading to the correct sw architecture, and avoiding to mix up the main security goal with the secondary one.

Nessun commento: