回答。

手动测试访问权限和角色可以检查不同类型的用户是否具备对应用程序功能和数据的正确访问权限。

问题的背景

随着用户数量和使用场景的增加，即使是简单的应用程序也开始采用角色模型。访问权限中的错误常常导致严重的数据泄露或业务操作的限制。因此，手动仔细测试角色的必要性应运而生。

问题

• 漏掉对敏感数据的访问限制的错误；
• 错误配置角色，导致用户执行不允许的操作（例如，普通用户访问管理功能）；
• 检查组合角色或非标准访问场景的困难。

解决方案

• 记录所有现有角色及其对应的操作；
• 为每个角色形成测试集，包括角色的条件交集；
• 检查对功能的访问，不仅包括对不同数据部分的访问（CRUD）；
• 验证直接访问（通过UI）和通过直接链接或API的访问尝试。

关键特性：

• 全面覆盖场景： 每种用户类型必须在所有可能的角色和操作中进行检查；
• 测试边界和组合角色： 错误往往在不同角色权限叠加时表现出来；
• 检查绕过标准接口： 测试无权用户对页面/操作的直接访问。

具有陷阱的问题。

只测试主要角色（例如，“管理员”和“用户”）是否足够？

不。通常，缺陷隐藏在中间、少用和组合角色中。

UI限制（隐藏按钮和元素）是否足够安全？

不。UI控制无法阻止直接地址或API的访问尝试，权限必须在服务器逻辑层面进行限制。

是否需要通过应用程序的不同渠道（例如，网页和移动应用）测试访问权限？

必须。不同实现间的差异常常导致行为上的不同和权限限制方面的错误。

常见错误和反模式

• 只检查标准角色
• 完全依赖外部接口，而不验证服务器限制
• 忽视非标准和组合角色

实际案例

负面案例

只检查了UI和三种主要角色。结果，具有非标准角色组合的用户通过直接链接访问了管理功能。

优点：

• 测试快速
• 流程简单

缺点：

• 在生产环境中发现严重漏洞
• 安全性和用户信任受到破坏

正面案例

为测试创建了各种角色组合的测试用户，进行API和直接访问审计。在发布之前发现并修复了错误。

优点：

• 高质量和安全性
• 降低内部和外部泄露的风险

缺点：

• 创建大量测试账户的时间成本
• 文档和与开发的协调增多