Secure protection for lazy modules (Angular 2)

Question

I am developing an application for which I have a user area and an administration area. I split them into separate Angular 2 modules. I successfully performed lazy loading so that the user module can only be loaded when the user asks for "/ admin".

From the Angular 2 documentation, I see that I can specify the "canLoad" protection like this:

{ path: 'admin', loadChildren: 'app/admin/admin.module#AdminModule', canLoad: [AdminGuard] } 

and implement the canLoad function inside the AdminGuard class as follows:

 canLoad(route: Route): boolean { return this.authService.isAdmin(); } 

(where isAdmin () can make an API call to the backend, which will return the role of the current user or something like that)

But does this really prevent the AdminModule from loading by the non-administrator? If I'm not mistaken, all this code is on the client, so is there something that can prevent the client from modifying the "canLoad" method so that it always returns true? For instance:

 canLoad(route: Route): boolean { return true; } 

Thus, the client can download any module that they need.

Obviously, any backend API calls that require administrator status will be protected, but it seems that any user will be able to view the admin user interface, which seems a little strange to me. Can someone clarify this for me?

Answer 1

This is a great question, and I was curious if anyone had a detailed answer to this question. So I found this link in which there was a pretty big conversation.

Angular 2 Reddit Article

One comment that really remained for me was that.

Speaking in SPA, usually html templates and your js files will be outdoors for anyone who is enough to check. Your SPA will appear on your server in the data (only: json), then the templates will be filled with this data on the client side. therefore, your main concern is protecting this API. Sessions, cookies, tokens - all this means that it is still valid here. I myself use tokens for authentication and authorization. The API request must contain a signed server token, which is then checked and from which roles and credentials is extracted, then used to determine that the user has the right to make this request. Failed verification will return a 401-unauthorized client. On the angular side, we save the token that we received after a successful login, and then use it for subsequent requests. I also decrypt credentials and roles, and it also displays user information and resolves routes. Angular route protection is achieved through the CanActivate interface, which you can associate with several of: {Path: 'protected', CanActivate: [LoggedInGuard]}, {Path: "supersecret", CanActivate: [LoggedInGuard, AdminGuard]} ... and etc. But the client side (read: angular) is ultimately a UX issue, not a security feature. A knowledgeable hacker can simply mess around with variables using the dev console or completely bypass it using a direct api call. This is pretty much to show users what error has occurred and navigate somewhere else, etc.