7

For an enterprise setting, how secure are Route Guards against script kiddies, hackers, and advanced threats?

If I understand correctly, the route guards are all available in .js files to the attacker and since all of the data is on the client-side, the user might be able to easily hack the route protection and manipulate flow logic.

  • Can the route guards be easily circumvented to access protected routes?
  • How good are the Route Guards from a security standpoint?
    • If they're bad, why do they even exist?
  • Isn't putting your logic from Front-End to Back-End API a better solution?
  • What security role/purpose do they serve then?

P.S This relates to Angular 8 and not AngularJS.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Sir Muffington
  • 1,447
  • 2
  • 9
  • 22

2 Answers2

12

Any client side restriction can be circumvented by an attacker. No client side restrictions should be relied upon to protect private data. These facts apply to all systems, and the fact that you are using Angular 8 doesn't change anything.

In practice what this means is that your server should not return any data that the logged in user should not access. If you were thinking of returning all data and having Angular guards decide whether or not to display it based upon the user's permission, then that is definitely the wrong approach. That sort of approach can be circumvented by an attacker of almost any skill level, because simply opening the developer tools on your browser and viewing network requests will allow anyone to view all the data.

Rather, the use of guards is simply for a nice UX. Without guards, what happens if the front-end allows a user to navigate to a page they aren't supposed to access? Presumably the user will receive some sort of "Access Denied" error and be very confused. However, if the Angular guards enforce the same set of privileges that the server does, then the user will never be able to visit a page they aren't supposed to visit, and therefore won't get confused by error messages. Note that your menu has to enforce the same rules. If your Angular guards would stop a user from going to a sensitive page but there is still a link to it on your menu anyway, then the user will be equally confused when they try to navigate to a secure page and the guards stop them.

Of course this only applies for legitimate users. An attacker of any skill level may find ways to hit your restricted server endpoints directly, so of course your server needs to check permissions too and return an appropriate "Access Denied" message.

tl/dr: Server side guards are about data protection. Client-side guards are about providing a smoother user experience.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • This. One of the constant issues I see in my $dayJob is the reliance on client-side to do the work. Especially in Angular, but other JS frameworks as well, where the server doesn't validate authentication or authorization, leading to exposure of data, or when the server returns all data, and leaves it in a JSON blob. Decoupling the frontend and backend encourages these practices. – h4ckNinja Nov 25 '19 at 18:53
  • Absolutely, agreed. – jburtondev Nov 26 '19 at 22:42
2

In Angular:

Routing guards do not provide security, however this still depends on the way that the full-stack of your application is built, we still need to be careful and not allow the api/application to load authenticated data for unauthenticated users. For example, if you guard a route, let's call it my-account in this case, by saying that only authenticated users can access this route (let's say this uses a token to authenticate the users requests), then this good practice will mean that only authenticated users can access this route, but if requests do not need to be authenticated, then this is still a huge vulnerability (if you have sensitive data for users, such as account details, etc).

However the most important thing is not protecting the route, it's ensuring that only users with the correct rights can access the data that they are allowed to access. This is because even if an attacker reverse engineers the code to access this route, if they are not authenticated, they cannot access the data.

This likely goes without saying, but do not hard-code sensitive values in your routes! because even if you guard them, they are still accessible to a moderately savvy attacker.

In closing, the key thing is to only allow authenticated users to access data that they are allowed to see, routes are for user experience as mentioned, not for security.

Hope this helps.

jburtondev
  • 121
  • 4