攻击者可以绕过任何客户端限制。不应依赖客户端限制来保护私人数据。这些事实适用于所有系统，而您使用 Angular 8 的事实并没有改变任何东西。

实际上，这意味着您的服务器不应返回登录用户不应访问的任何数据。如果您正在考虑返回所有数据并让 Angular 守卫根据用户的许可决定是否显示它，那么这绝对是错误的方法。几乎任何技术水平的攻击者都可以绕过这种方法，因为只需在浏览器上打开开发人员工具并查看网络请求，任何人都可以查看所有数据。

相反，使用守卫只是为了一个好的用户体验。如果没有警卫，如果前端允许用户导航到他们不应该访问的页面会发生什么？大概用户会收到某种“拒绝访问”错误并且非常困惑。但是，如果 Angular 守卫强制执行与服务器相同的权限集，那么用户将永远无法访问他们不应该访问的页面，因此不会被错误消息弄糊涂。请注意，您的菜单必须执行相同的规则。如果你的 Angular 守卫会阻止用户访问敏感页面，但无论如何在你的菜单上仍然有指向它的链接，那么当用户尝试导航到安全页面并且守卫阻止他们时，他们同样会感到困惑。

当然，这只适用于合法用户。任何技术水平的攻击者都可能想方设法直接攻击您的受限服务器端点，因此您的服务器当然也需要检查权限并返回适当的“拒绝访问”消息。

tl/dr：服务器端防护是关于数据保护的。客户端防护旨在提供更流畅的用户体验。

在角：

路由守卫不提供安全性，但这仍然取决于构建应用程序全栈的方式，我们仍然需要小心，不允许 api/应用程序为未经身份验证的用户加载经过身份验证的数据。例如，如果您保护一条路由，我们my-account在这种情况下调用它，通过说只有经过身份验证的用户才能访问此路由（假设这使用令牌来验证用户请求），那么这种良好做法将意味着只有经过身份验证的用户可以访问这个路由，但是如果请求不需要认证，那么这仍然是一个巨大的漏洞（如果你有用户的敏感数据，例如帐户详细信息等）。

但是最重​​要的不是保护路由，而是确保只有拥有正确权限的用户才能访问他们被允许访问的数据。这是因为即使攻击者对代码进行逆向工程以访问此路由，如果他们未经身份验证，他们也无法访问数据。

这可能不言而喻，但不要在您的路线中硬编码敏感值！因为即使您保护它们，中等精明的攻击者仍然可以访问它们。

最后，关键是只允许经过身份验证的用户访问他们被允许查看的数据，路由是为了用户体验，而不是为了安全。

希望这可以帮助。