先直接说结论：仅在前端实现授权几乎没有真正的安全价值，最多只能做用户体验层面的优化；而前后端同时做授权是Web应用安全的基本准则。

仅前端做授权的“可取之处”（仅限极端场景） #

说实话，这种方案只有在完全没有敏感数据、纯静态展示的项目里才有点意义——比如一个纯展示公司新闻的静态网站，用户权限完全不影响内容，前端做个菜单隐藏只是为了让界面更干净。但哪怕是这种场景，也谈不上“安全机制”，只是UI层面的优化。

如果你的项目涉及用户专属数据、操作权限（比如修改内容、删除数据、管理员功能），那前端单独做授权等于完全没做安全防护。

为什么必须前后端同时实现授权？ #

咱做开发的都知道，前端是完全暴露在用户面前的，任何前端的权限限制都能被轻易绕过：

• 用户可以直接绕过前端调用API：比如前端隐藏了管理员的“删除用户”按钮，但用户只要打开浏览器控制台，用fetch或者Postman直接调用/api/users/delete/123接口，如果后端没做权限校验，请求就会直接执行。
• 前端代码可被随意修改：用户可以通过修改本地JS代码、禁用前端权限校验逻辑，直接看到原本被隐藏的敏感内容或操作入口。
• 数据泄露风险：如果后端不校验权限，用户可以通过API获取不属于自己的数据——比如普通用户调用/api/admin/statistics拿到全站运营数据，这完全是后端的失职。
• 合规与审计要求：很多行业（金融、医疗、政务）的合规标准明确要求后端必须做权限校验，前端的限制只能作为辅助，否则根本过不了安全审计。

另外，ASP.NET Core本身就提供了非常成熟的授权机制，比如用[Authorize]特性、角色授权、自定义权限策略，这些都是官方推荐的安全实践，直接用就好，没必要舍近求远。

怎么和资深开发沟通这个问题？ #

建议用实际场景+逻辑推导的方式，避免空泛的争论：

1. 现场演示漏洞：找个测试环境，当着他的面用Postman调用一个需要权限的后端接口，不携带任何权限凭证（或者用普通用户的凭证），如果接口直接返回数据/执行操作，那这个漏洞就是最有力的证据。
2. 明确职责划分：前端的授权是“体验层”——比如根据权限隐藏按钮、跳转页面，让用户不用做无意义的操作；后端的授权是“安全层”——真正拦截所有非法请求，是最后一道防线。两者是互补的，不是二选一。
3. 从维护成本角度出发：如果以后前端框架更换（比如从React换成Vue），后端的权限校验依然有效，不用重复开发；如果只做前端，换框架后还要重新实现一遍权限逻辑，而且很容易遗漏细节。
4. 引用行业共识：可以提一下OWASP安全指南里的明确要求——服务器端的权限校验是必须的，客户端的校验只能作为辅助，这是行业公认的安全准则。

内容的提问来源于stack exchange，提问作者DexterBoyGenius