Guards cannot guarantee the confidentiality of parts of the application

[Jan-PeterRichterCG]

Category: Bug

Severity: Medium

Expected behaviour (In case of bug)
The tutorial should give advice how to implement confidentiality in a secure way.

Actual/current behaviour (In case of bug)
The tutorial advises to use Guards in order to securely hide confidential parts of the application from an umpriviledged user.

Steps to reproduce (In case of bug)
(read the tutorial)

Description of issue / expected enhacement /Comments
https://github.com/devonfw/devonfw-tutorial-sources/wiki/angular-services on Guards:

We encourage to use Guards, because even if you hide the button to navigate, the user can modify the URL in the browser and have access to the component, with guards implemented, this navigation will be forbidden and you app not compromised.

IMHO even Guards cannot guarantee that a "forbidden part" is not compromized. If it is absolutely neccessary to hide a part of the application from an (unprivileged) user, it is necessary to implement an authorization scheme on the server side along with dynamic loading of that part of the application [dynamic loading may already be the standard in Angular already - I'm not familiar with Anguar yet.] . This will result in not being able to retrieve the http/JavaScript code that comprises the "forbidden" parts of the application.
Guarding can always be broken by an attacker by removing the Guard in the running code in the browser - which is under the total control of the user.
Of course, using Guards is the right way to hide parts of the app that should not be accessible. But the reason is usability ("I do not see any parts of the GUI that I am not allowed to use anyway"), not confidentiality ("I do not see any parts of the GUI that I must not get to know").

Your environment - windows/Linux, Devonfw version , component
irrelevant

[sjimenez77]

Hi @Jan-PeterRichterCG,

I disagree about your Guards statement. What Guards guarantee is that a specific route in your frontend app is accessible or not depending on some criteria that the developer will specify implementing the proper methods as stated in the Angular documentation https://angular.io/guide/router#milestone-5-route-guards. Removing the Guards in the running code is really challenging and I encourage you to take a look to the generated code in the Chrome Dev Tools in any Angular application in production in order to find out if it is possible to do it. Angular is developed by Google and I can imagine that the security is a critical topic to them.

In this case, a simple tutorial, the developers will develop a canActivate method to find out if the user can or cannot access a particular route.

The mechanism is proved and used in multiple projects, but of course has to be properly aligned and validated with the security mechanisms at backend. For example canActivate could check if the user has a correct JWT or CSRF tokens in browser memory or cache that will be sent automatically in HTTP requests via interceptors. If the user sents a request with an expired or not valid token for example the server will respond with an error and the next canActivate execution will redirect the user to the login form.

Best regards,
Santos